Second Life Wiki - User contributions [en]

Linden Lab Official:User Groups

2024-08-08T22:24:07Z

Log Linden:

{{Current Events Nav}}
== About Second Life User Groups ==

User groups are product or community focused and each one is led by the product manager or community manager. Our goals are to make it easier for you to find the user group, or groups, that you want to participate in and for us to listen more closely to your needs and ideas. The user group program is about opening up more lines of communication. Most user groups are public and include inworld meetings, JIRA sections, and sometimes a Twitter feed, an SL Forum, or an SL email list. It's up to the user group lead and the core Resident team how they want to communicate with one another. The discussions will be open, direct, and focus more on your needs, new features, and be more forward-looking.

All Residents who join user groups must comply with the new [[Linden_Lab_Official:Community_Participation_Guidelines| Community Participation Guidelines]], in addition to our [http://secondlife.com/corporate/tos.php Terms of Service]. These guidelines ensure that all conversations are constructive, courteous, respectful, and in the spirit of collaboration.

{{KBnote|User groups ''aren't'' for support help. Instead, use the [http://secondlife.com/support Support Portal].}}

== Public User Group Meetings ==

For information on dates and times of user group meetings, see the user groups meeting schedule. And, each User Group has an individual page where agendas and archives reside. The program is still getting up to speed, so give each User Group leader time to fill in their content. Check back often!

All times listed are [http://www.timeanddate.com/worldclock/city.html?n=224 Pacific Time].

NOTE: By default, the table below is sorted chronologically by day of the week. To sort alphabetically on any other column, click the icon in the column heading.

{| class="lltable sortable" border=1
!width=120|User Group
!width=200|Description
!width=120|User Group Leader
!Frequency
!width=120|Days of Week
!width=100|Time (PT)
!Location (SLurl)

|-
| {{User Group|Server/Sim/Scripting}}
| Simulator issues and technology.
| Simon Linden
| Weekly
| Tuesday
| 12:00-13:00
| http://maps.secondlife.com/secondlife/Denby/217/45/32

|-
| {{User Group|Open Development}}
| Open discussion of SL development, including open source contributions.
| Vir Linden
| Bi-Weekly
| Wednesday
| 07:00-08:00
| {{SLurl|region=Hippotropolis|x=209|y=90|z=24|title=Oz's Raft}} or {{SLurl|region=Hippo Hollow|x=182|y=49|z=44}}

|-
| {{User Group|Content Creation}}
| Discussion of SL content creation including avatars, animations, and other meshes. (Supersedes the Bento user group.)
| Vir Linden
| Bi-Weekly
1st, 3rd, and 5th Thursdays
| Thursday
| 13:00-14:00
| {{SLurl|region=Hippotropolis|x=71|y=172|z=30|title=Hippotropolis Campfire Circle}}

|-
| {{User Group|Concierge & Land}}
| Discussion & education of SL topics such as current known issues and bugs, project viewers and new features, and general Mainland issues.
| Wendi Linden & Vix Linden
| Every 4th Wednesday
| Wednesday
| 12:00-13:00
| [http://maps.secondlife.com/secondlife/Linden%20Estate%20Services4/228/16/28 Linden Estate Services4 228,16,28]

|-
| {{User Group|Web}}
| Discussion of issues around Web properties such as Marketplace, Profiles, Place Pages, Search, etc.
| Sntax Linden
| Monthly
| Wednesday
| 14:00
| http://maps.secondlife.com/secondlife/Denby/73/78/25

|-
| {{User Group|Skill Gaming}}
| Discussion of anything pertaining to the Skill Gaming Program. How to be part of the SLSG Program, questions about processes, and any known issues or concerns.
| Corky Linden
| Every 2nd Tuesday.
| Tuesday
| 11:00 - 12:00
| http://maps.secondlife.com/secondlife/Havenhurst/92/159/21

|-
| {{User Group|Governance}}
| Discussion of topics relating to safety and security in Second Life. Please note this does not include the discussion of Reports anyone has filed, the outcome of investigations, or potential actions taken on abuse, DMCA or copyright issues.
| Keira Linden
| Monthly, Every 2nd Thursday
| Thursday
| 14:00 - 15:00
| [http://maps.secondlife.com/secondlife/Linden%20Estate%20Services4/228/16/28 Linden Estate Services4 228,16,28]
|}

[[Category:User Groups]]

[[Category:User Groups]]

Message Template

2023-11-22T18:55:38Z

Log Linden: We use git for the message template now. We had updated the URI to the github repository but still claimed it was a mercurial repository.

{{OSWikiLearnBox|parent=Protocol}}

The message template describes all of the [[message]]s that Second Life uses to communicate between hosts. All message templates must match a CRC check between hosts, otherwise they will not communicate with each other.

The master message template is stored in a public git repository at:
https://github.com/secondlife/master-message-template

== See also ==
* [[Message]]s
* [[Packet Layout]]
* [http://lib.openmetaverse.org/template/ Template archive at libopenmetaverse]
* [https://github.com/cinderblocks/libremetaverse/tree/master/data/ LibreMetaverse (living fork of LibOpenMetaverse)]

Logging System Overview

2019-08-19T18:30:52Z

Log Linden: Fixed typo in example logcontrol.xml that was causing parser error

This document explains how to use the Second Life logging system in the SL Viewer and Simulator, in executable and runtime configuration.

== Overview ==

Enable all developer functionality by including "'''llerror.h'''" (in llcommon). Configure runtime settings with the log control file, as described in [[#Runtime control|Runtime control]].

To get the maximum utility out of the log system, add the following
to the private section of your class declaration:

<source lang="cpp">LOG_CLASS(LLFoo);</source>

For example:

<source lang="cpp">
class LLFoo
{
LOG_CLASS(LLFoo);
public:
...
};</source>

===Output===
The Viewer saves log output to <code>LL_PATH_APP_SETTINGS/logs/SecondLife.log</code>, where LL_PATH_APP_SETTINGS is:
* <code>%APPDATA%\SecondLife\</code> on Windows.
* <code>$HOME/Library/Application Support/SecondLife/</code> on MacOS.
* <code>$HOME/.secondlife/</code> on Linux.

The server sends log output to <code>/var/log/indra.log</code>.

== Logging macros ==

To selectively enable or disable log messages at runtime, use log message tag strings (a "broad" scope tag and a "narrow" scope tag). For an example, see the '''<key>tags</key>''' block in [[#Runtime_control|Runtime control]].

If you really don't want to tag a message, pass NULL to the macro. However, the overhead of logging a message is small.

=== Basic macros ===
Use the base macros as follows:

<source lang="cpp">LL_DEBUGS("BroadScopeTag") << "A debug level log message" << LL_ENDL;
// This is a macro, not a string stream. The "LL_ENDL" is required.
LL_INFOS("BroadScopeTag") << "An info level log message" << LL_ENDL;
LL_WARNS("BroadScopeTag") << "A warning level log message" << LL_ENDL;
LL_ERRS("BroadScopeTag") << "An error level log message" << LL_ENDL;
// LL_ERRS forces a crash of the viewer.</source>

The logging macros behave like iostreams. You can appended anything to them that can be appended to an iostream.

=== Dual tag macros ===

With dual tag macros, you to bind two string tags to a log message: a "broad" scope tag and a "narrow" scope tag, useful to specify a high granularity and a low granularity tag for a log message. For example, you could specify "AppInit" and "SystemInfo" tags, where "AppInit" is the broad scope tag for the long application initialization process of which the narrow scope tag "SystemInfo" printing is a small portion.

<source lang="cpp">LL_DEBUGS2("BroadScopeTag", "NarrowScopeTag") << "A debug level log message" << LL_ENDL;
// NOTE: This is a macro, not a string stream. The "LL_ENDL" is required.
LL_INFOS2("BroadScopeTag", "NarrowScopeTag") << "An info level log message" << LL_ENDL;
LL_WARNS2("BroadScopeTag", "NarrowScopeTag") << "A warning level log message" << LL_ENDL;
LL_ERRS2("BroadScopeTag", "NarrowScopeTag") << "An error level log message" << LL_ENDL;
// NOTE: LL_ERRS2 force a crash of the viewer.</source>

=== Tag formatting ===

Format macro tags in "camel case", such as "RenderInit" and "TextureCache".

'''Tags may not contain whitespace characters'''

=== Obsolete macros ===

In the past, the "'''llerrs'''", "'''llwarns'''", "'''llinfos'''", "'''lldebugs'''", and "'''llendl'''" macros were less capable versions of the current system. For a long time, they were allowed, but now they have been replaced with those documented here and removed.

== Logging a repeating message only once ==

Sometimes log messages will get triggered repeatedly, filling the log file with the same exact message string over and over. To avoid cases like this, use the "ONCE" macros
These macros print the message the first time, prepending "ONCE: " to the message string. Subsequently, when it is triggered '''with the same message''' it will print only the 10th, 50th, or every 100th time thereafter. Then, it updates you by prepending "ONCE (Nth time seen): " to the log message, where N is the number of times it has been seen.

'''Note:''' This works on unique final log messages, so log messages that depend on one or more variables have the final output treated as different messages if any part of the string changes. Thus, you should not use ONCE macros for log messages that will print many times but with different messages, as this would be slightly slower and would slowly fill up a std::map with memory occupying junk.

<source lang="cpp">LL_DEBUGS_ONCE("BroadScopeTag") << "A debug level log message" << LL_ENDL;
// NOTE: This is a macro, not a string stream. The "LL_ENDL" is required.
LL_INFOS_ONCE("BroadScopeTag") << "An info level log message" << LL_ENDL;
LL_WARNS_ONCE("BroadScopeTag") << "A warning level log message" << LL_ENDL;

LL_DEBUGS2_ONCE("BroadScopeTag", "NarrowScopeTag") << "A debug level log message" << LL_ENDL;
// NOTE: This is a macro, not a string stream. The "LL_ENDL" is required.
LL_INFOS2_ONCE("BroadScopeTag", "NarrowScopeTag") << "An info level log message" << LL_ENDL;
LL_WARNS2_ONCE("BroadScopeTag", "NarrowScopeTag") << "A warning level log message" << LL_ENDL;</source>

For example, the following log message:

<source lang="cpp">LL_WARNS_ONCE("Drawable") << "Drawable becomes static with active parent!" << LL_ENDL;</source>

Will print the following messages to <code>SecondLife.log</code> if it kept getting called repeatedly:

WARNING: LLDrawable::makeStatic: ONCE: Drawable becomes static with active parent!
WARNING: LLDrawable::makeStatic: ONCE (10th time seen): Drawable becomes static with active parent!
WARNING: LLDrawable::makeStatic: ONCE (50th time seen): Drawable becomes static with active parent!
WARNING: LLDrawable::makeStatic: ONCE (100th time seen): Drawable becomes static with active parent!
WARNING: LLDrawable::makeStatic: ONCE (200th time seen): Drawable becomes static with active parent!
...

== Runtime control ==

Configuration runtime settings with the ''log control file'', an XML file that the application loads immediately
after initialization. First, it tries to load <code>logcontrol-dev.xml</code>. If that file doesn't exist, then it loads <code>logcontrol.xml</code> instead. The application checks the file for changes every couple of seconds and reloads it if necessary.

Put the <code>logcontrol-dev.xml</code> file into your user settings directory '''before launching the viewer'''.

=== Sample Control File ===

The following is a sample <code>logcontrol.xml</code> file that sets the default loggging level to WARN and then conditionally turns on some warnings at INFO level and DEBUG level based on "function name", "class name", "file name", and "tag".

<source lang="xml">
<llsd>
<map>

<key>default-level</key> <string>WARN</string>
<key>print-location</key> <boolean>false</boolean>
<key>settings</key>
<array>
<map>
<key>level</key><string>INFO</string>
<key>functions</key>
<array>
<string>LLAgentInfo::handleImageRequest</string>
</array>
<key>classes</key>
<array>
<string>LLBufferArray</string>
</array>
<key>files</key>
<array>

<string>newview/lldrawpoolavatar.cpp</string>
</array>
<key>tags</key>
<array>
<string>AppInit</string>
<string>TextureCache</string>
</array>
</map>
<map>
<key>level</key><string>DEBUG</string>
<key>functions</key>
<array>
</array>
<key>classes</key>
<array>
</array>
<key>files</key>
<array>
<string>llui/llbutton.cpp</string>
<string>llui/llcombobox.cpp</string>
</array>
<key>tags</key>
<array>
<string>RenderInit</string>
</array>
</map>
</array>
</map>
</llsd></source>

== Logging granularity conflict resolution ==

The logging system decides in the following order what logging granularity to apply to a message:

# Default log level
# BroadScopeTag
# File Name
# Class Name
# Function Name
# NarrowScopeTag

The application uses the highest matching priority level found in the log control file to determine whether to print a particular log message. For example, if a given log message is of a class set in the log control file to print all '''LL_DEBUGS()''' and below, but there is an entry for its function name that states to print only '''LL_WARNS()''' and below, then the system will print only '''LL_WARNS()''' and '''LL_ERRS()'''.

== Continuing a log message after further computation ==

Use the '''LL_CONT''' macro if you need to do computation in the middle of a log message:

<source lang="cpp">
LL_DEBUGS("AgentGesture") << "the agent " << agend_id;
switch (f)
{
case FOP_SHRUGS: LL_CONT << "shrugs"; break;
case FOP_TAPS: LL_CONT << "points at " << who; break;
case FOP_SAYS: LL_CONT << "says " << message; break;
}
LL_CONT << " for " << t << " seconds" << LL_ENDL;
</source>

Make sure to remember the '''LL_ENDL''' at the end and '''ONLY''' at the end.

Any computation embedded as above is done only if the message will be logged.

This means that you can also use the macro functionality to conditionally call separate functions only if that granularity of logging is enabled, such as in the following example from <code>llfeaturemanager.cpp</code>:

<source lang="cpp">
LL_DEBUGS("RenderInit") << "After applying mask " << mask.mName;
// Will conditionally call dump only if the above message will be logged, thanks
// to it being wrapped by the LL_DEBUGS and LL_ENDL macros.
dump();
LL_CONT << LL_ENDL;
</source>

= Log Line Format =

Log entries are written as a single line formatted as:
''timestamp'' SPACE ''level'' SPACE ''tags'' SPACE ''location'' SPACE ''function'' SPACE COLON SPACE ''message''

Where
* ''timestamp'' is an ISO format date/time stamp like <tt>2018-09-19T13:38:53Z</tt>
* ''level'' is the severity level
* ''tags'' is any tag values, surrounded by '#' characters, or a single '#' if there are no tags specified, like <tt>#HTTPCore#</tt> or <tt>#HTTPCore#Initialize#</tt>
* ''location'' is the path name (relative to the top level <tt>indra</tt> directory) and line number in parenthesis like <tt>llcorehttp/httpstats.cpp(104)</tt>
* ''function'' is the class and method or function name like <tt>LLControlGroup::get</tt>
* SPACE is a single space character
* COLON is a single colon character (':')
* ''message'' is the log message, with any backslash, newline, and return characters escaped (see below)

For example:
2018-09-19T13:38:53Z WARNING #HTTPCore# llcorehttp/httpstats.cpp(104) dumpStats : HTTP DATA SUMMARY\nHTTP Transfer counts:\nData Sent: 0B (0)\nData Recv: 0B (0)\nTotal requests: 4(request objects created)\n\nResult Codes:\n--- -----\n200 1\n

== Log Line Escaping ==

The log message may be multiple lines; any line breaks will be escaped by substituting
newline → \n
return → \r
\ → \\

This escaping can be undone for readability by piping the log file through a filter like:
perl -pe 's/\\\\/\\/g; s/\\n/\n/g; s/\\r/\r/g;'

The example line above when run through that filter becomes:
2018-09-19T13:38:53Z WARNING #HTTPCore# llcorehttp/httpstats.cpp(104) dumpStats : HTTP DATA SUMMARY
HTTP Transfer counts:
Data Sent: 0B (0)
Data Recv: 0B (0)
Total requests: 4(request objects created)

Result Codes:
--- -----
200 1

Project Sunshine-Server Side Appearance

2012-12-14T21:49:43Z

Log Linden:

= Server Side "Texture Baking" Viewer Release =

== Structure of Server side texture baking ==

[[Image:Server Side Appearance Architecture.png|720px]]

== Viewer Architecture changes ==

In order to accomodate the back-end server code we have refactored a significant portion of the avatar appearance pipeline. There is now a new "project" in the indra directory called "llappearance" which defines a set of interface and functional classes that are shared between the viewer and the back end rendering system. These classes were pulled out of newview, and range from avatar definitions (LLVOAvatar), to tex layers and visual parameters. In addition, a number of texture functions and classes have been moved from newview to llrender. In some cases, these classes were subclassed to contain the viewer-specific functionality back in newview.

Since some of the functionality of the classes was moved to a different directory while other pieces stayed, many merge tools will get confused and not necessarily move your changes to the correct place and in some cases may believe that the proper solution is to remove your fixes or be unable to merge the patches at all. Expect that there will be some manual merging necessary, especially if your viewer has made avatar/appearance changes or tweaks. We will assist whenever possible with questions about the new architecture or merge questions, but the new changes will be necessary for viewers to have after we start to roll out new servers.

 

== New Network Protocols ==

To support the new featureset, a few of the network protocols have been modified or added to:

#login now returns a texture fetch url for any baked texture requests 
#Agent Appearance message now contains an extra visual parameter to indicate that it is a new-style message
#Agent Appearance message has an extra (optional) block to indicate appearance version number and current outfit folder version number
#Regions now have a new capability to request an appearance message which will return or regenerate the agent appearance message
#Regions will soon have a new capability to request an increase in current outfit folder verion (see below).

== Forwards and Backwards Compatibility ==

This project was designed under the assumption that viewers will be updated before the server code gains widespread adoption. However, the server code will take a while to test, scale up, and roll out. As such, the viewer code provided can work fine on the grid as it stands today. The new code should still upload new baked textures and use the old protocols on the main grid. Once a new viewer connects to a new server, that user's appearance message will be converted to a server-generated message that will persist even once you return to an old region. New-style appearance messages will remain flagged as such even when sent by an old region. Since textures are fetched from a central service, updated viewers will be able to fetch an avatar's textures even if the server does not support it.

If you force a rebake or change your outfit while standing on an old-style region, however, your viewer will revert to uploading its own bakes. These will be overwritten when you return to a new-style region.

Our testing regions on Aditi are set up next to some server-trunk regions so that you can test these transitions. Please be certain to test with multiple viewers so that you can verify that avatar appearance is consistent from multiple users.

== Status of viewer repository ==

This code is provided as pre-alpha quality. We have done a recent merge from viewer-development, and QA has done a quick test to verify that there are not major regressions. However, it is not production ready and there will be additional patches and bug fixes that will need to be intergrated before release. We are releasing the current state of code to get feedback, identify and isolate bugs, and provide extra time for alternate viewers to start the merging process. Please do not merge this into your main repository, but start a fresh fork that can be merged in once the code is stabilized.

 

Initial testing appears to indicate that this viewer does the correct thing in most cases of login, region crossing between new and old simulators, etc. There are a few known bad edge cases currently:

#Saving a wearable item while making no other changes to your appearance does not update your appearance. We're adding a new capability that will compensate for this case, and a fallback for old regions in the mixed-grid case. 
#Initial appearance message after transitioning from an old region to a server-bake region may send an inaccurate appearance, with COF version = 0.
#Bakes on aditi will be overlayed with some hex values (the first few digits of their UUIDs). This is temporary and on purpose (for determining whether an image is a local or a server-generated bake). This will be removed before release.
 

Keep checking in for additional information on known issues and updates. More code will be pushed periodically as we fix the remaining issues and make any refinements.

While the code is not finished, it does appear to be functional enough to test and we do not anticipate additional major refactoring. Please start your merge work soon, and let us know when your release schedule will allow you to present the new viewers to your userbase. Once we start rolling out the new server code on the main grid, viewers that have not been updated will fail to resolve avatar appearance for themselves and others. Avatars that have changed their appearance on a new-style region will continue to appear incorrectly even after moving back to current server-trunk regions.

 

== Reporting Bugs, assistance with merge issues ==

The viewer should work as it does today on the main grid. There are regions on Aditi that have the new code ( SunshineTest, SunshineTest1 ).

Bugs and edge cases with the current state of code, whether in the viewer code or the back-end service should be filed in JIRA under project sunshine ([https://jira.secondlife.com/browse/SUN SUN]). If you are a developer and cannot access this project, contact [[User:Oz_Linden]].

If you are having trouble with the new re-architecture or merging your appearance changes into the new codebase, please reach out to Nyx Linden (nyx at lindenlab.com).

 

== Source code & build links ==
{{ViewerInstallers|{{JiraIssue|SUN|Server Side Texture Baking}}| Support server side texture baking. |task=sunshine-external|repo=https://bitbucket.org/lindenlab/sunshine-external}}

User:Log Linden/Socks5Viewer/TestPlan/ProxyGateway

2012-04-30T22:40:47Z

Log Linden: /* Packet Capture Tools */

= Introduction =
These instructions will help you set up a simple Ubuntu gateway machine that will allow you to control access to the outside network for computers that are operating behind the gateway. This setup was created for testing the SOCKS 5 proxy. With some modification, the same setup could be used for testing various other network conditions, including throttling the connection speed down to something closer to residential DSL speeds. The instructions are intended for someone with a reasonable familiarity with Ubuntu Linux and will only discuss the customisations needed to set up the gateway.

= Requirements =
== Hardware ==
* A standard off-the-shelf PC with two Ethernet NICs
* 1 Ethernet switch for the "internal" network
* Network cables
* Other computers to actually test the viewer on.

== Software ==
* Ubuntu Linux 11.04 (Natty) [http://www.ubuntu.com/download/ubuntu/download install media] (Other flavors of Ubuntu, including Ubuntu server should work with these instructions as well.)

= Instructions =
== Connect network hardware ==
* Connect one network card to the outside network.
* Connect the other network card to the internal ethernet switch.
* Connect testing computers to the internal network switch.
[[File:Socks_test_setup.2.png|border|600px|SOCKS Testing Network Setup]]

== Install Ubuntu and Packages ==
* Install Ubuntu on the gateway machine. Consult the official Ubuntu install [https://help.ubuntu.com/community/GraphicalInstall instructions] for more information.
* Reboot into the installed system.
* Update the packages on the system.
<bash>
sudo apt-get update
sudo apt-get upgrade
</bash>
* Install some additional useful packages that we will need.
<bash> sudo apt-get install dnsmasq dante-server openssh </bash>
== Configure Network Interfaces ==
* IMPORTANT NOTE: For the purpose of this document, eth0 is the device that is connecting to the outside network, and eth1 is connecting to the internal network. Verify which is which on your setup.
<bash>ifconfig</bash>
Chances are, only one of the ethX devices will have been assigned an IP address by your network, this is the one connected to the external network. If this is not eth0 you need to either switch the network cables connected to the computer or remember to swap the interface names everywhere in the rest of this document. We are going to be assigning eth1 with a static IP address, which can cause problems if it conflicts with the rest of your network.
* Edit, with sudo, '/etc/network/interfaces' and replace its contents with the following
<bash>
auto lo eth0 eth1

iface lo inet loopback

# External network
iface eth0 inet dhcp

# Internal network
iface eth1 inet static
address 192.168.1.1
network 192.168.1.0
netmask 255.255.255.0
broadcast 192.168.1.255
</bash>
* This configuration makes eth0 continue to get its configuration through DHCP, and statically configures eth1. Listing both interfaces on the auto line will mean that they will automatically connect on startup.
* Because we are setting up the interfaces in this config file, we should probably prevent networkmanager from trying to do it as well.
<bash> sudo update-rc.d NetworkManager remove</bash>
* Restart the network
<bash>
sudo /etc/init.d/networking stop
sudo /etc/init.d/networking start
</bash>
* Verify the network configuration by looking for the correct IP addresses for eth0 and eth1.
<bash> ifconfig</bash>

== Set up DNS and DHCP ==
* dnsmasq is a lightweight combination DNS/DHCP server. For the anticipated number of clients for this network, it should be sufficient.
* Warning: Again, it is important to get the network interfaces correct for this. Running a rogue DHCP server on the wrong interface could cause major network problems. eth1 should be the '''internal''' network card.
* Replace /etc/dnsmasq.conf with the following:
<bash>
interface=eth1

dhcp-range=192.168.1.50,192.168.1.150,12h
dhcp-authoritative
dhcp-script=/bin/echo
</bash>
* Restart dnsmasq
<bash> sudo /etc/init.d/dnsmasq restart </bash>

== Set up the Firewall ==
* Save the following two scripts to ~/scripts
=== nat_forward_all.sh ===
<bash>
echo -e "\n\nLoading simple rc.firewall-iptables version $FWVER..\n"
DEPMOD=/sbin/depmod
MODPROBE=/sbin/modprobe

EXTIF="eth0"
INTIF="eth1"
echo " External Interface: $EXTIF"
echo " Internal Interface: $INTIF"

#======================================================================
#== No editing beyond this line is required for initial MASQ testing ==
echo -en " loading modules: "
echo " - Verifying that all kernel modules are ok"
$DEPMOD -a
echo "----------------------------------------------------------------------"
echo -en "ip_tables, "
$MODPROBE ip_tables
echo -en "nf_conntrack, "
$MODPROBE nf_conntrack
echo -en "nf_conntrack_ftp, "
$MODPROBE nf_conntrack_ftp
echo -en "nf_conntrack_irc, "
$MODPROBE nf_conntrack_irc
echo -en "iptable_nat, "
$MODPROBE iptable_nat
echo -en "nf_nat_ftp, "
$MODPROBE nf_nat_ftp
echo "----------------------------------------------------------------------"
echo -e " Done loading modules.\n"
echo " Enabling forwarding.."
echo "1" > /proc/sys/net/ipv4/ip_forward
echo " Enabling DynamicAddr.."
echo "1" > /proc/sys/net/ipv4/ip_dynaddr
echo " Clearing any existing rules and setting default policy.."https://wiki.secondlife.com/w/index.php?title=User:Log_Linden/Socks5Viewer/TestPlan/ProxyGateway

iptables-restore <<-EOF
*nat
-A POSTROUTING -o "$EXTIF" -j MASQUERADE
COMMIT
*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A FORWARD -i "$EXTIF" -o "$INTIF" -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -i "$INTIF" -o "$EXTIF" -j ACCEPT
-A FORWARD -j LOG
COMMIT
EOF

echo -e "\nrc.firewall-iptables v$FWVER done.\n"
</bash>
=== nat_block_all.sh ===
<bash>
echo -e "\n\nLoading simple rc.firewall-iptables version $FWVER..\n"
DEPMOD=/sbin/depmod
MODPROBE=/sbin/modprobe

EXTIF="eth0"
INTIF="eth1"
echo " External Interface: $EXTIF"
echo " Internal Interface: $INTIF"

#======================================================================
#== No editing beyond this line is required for initial MASQ testing ==
echo -en " loading modules: "
echo " - Verifying that all kernel modules are ok"
$DEPMOD -a
echo "----------------------------------------------------------------------"
echo -en "ip_tables, "
$MODPROBE ip_tables
echo -en "nf_conntrack, "
$MODPROBE nf_conntrack
echo -en "nf_conntrack_ftp, "
$MODPROBE nf_conntrack_ftp
echo -en "iptable_nat, "
$MODPROBE iptable_nat
echo -en "nf_nat_ftp, "
$MODPROBE nf_nat_ftp
echo "----------------------------------------------------------------------"
echo -e " Done loading modules.\n"
echo " Enabling forwarding.."
echo "1" > /proc/sys/net/ipv4/ip_forward
echo " Enabling DynamicAddr.."
echo "1" > /proc/sys/net/ipv4/ip_dynaddr
echo " Clearing any existing rules and setting default policy.."

iptables-restore <<-EOF
*nat
-A POSTROUTING -o "$EXTIF" -j MASQUERADE
COMMIT
*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A FORWARD -i "$INTIF" -j LOG
-A FORWARD -i "$INTIF" -j REJECT
COMMIT
EOF

echo -e "\nrc.firewall-iptables v$FWVER done.\n"
</bash>
* Make both scripts executable
<bash>
chmod a+x ~/scripts/nat_block_all.sh
chmod a+x ~/scripts/nat_forward_all.sh
</bash>
* Test the wide-open script. Inspect the output for errors indicating something is wrong.
<bash>
sudo ~/scripts/nat_forward_all.sh
</bash>
* If the previous command was successful and you got dns and dhcp configured before, you should be able to connect through your gateway on computers on the internal network.
* Test this now, by connecting a test computer to the network if you haven't already. Try browsing the web on one of the test machines as a quick test. Use '''ipconfig /all''' or '''ifconfig''' to see how the test computer is being configured. Expected values are below:
{| class="lltable" border="1"
|+ '''Test Machine Network Parameters'''

|--
!Parameter
!Expected Value

|--
| IP Address
| 192.168.1.50-192.168.1.150

|--
| Subnet Mask
| 255.255.255.0

|--
| Default Gateway
| 192.168.1.1

|--
| Nameserver (DNS Server)
| 192.168.1.1

|}

* If everything seems to be working correctly, make the wide-open config run during system startup.
<bash>
sudo cp nat_forward_all.sh /etc/init.d/nat.sh
sudo ln -s /etc/init.d/nat.sh /etc/rc2.d/S95masquradescript
</bash>

== Set up the SOCKS 5 proxy==
* Replace /etc/danted.conf with the following.
<pre>
logoutput: /var/log/dante.log

internal: eth1 port = 1080

external: eth0

method: username none
# Accept either username auth or no auth. If using username auth, use the same username and password that are used to sign on to this machine.

#user.privileged: proxy
user.notprivileged: nobody

### "client-rules" ###

client pass {
from: 192.168.1.0/24 port 1-65535 to: 0.0.0.0/0
}

client block {
from: 0.0.0.0/0 to: 0.0.0.0/0
log: connect error
}

### "socks-rules" ###
# Block connections to loopback interfaces
block {
from: 0.0.0.0/0 to: 127.0.0.0/8
log: connect error
}

# Allow udp reply packets from outside
pass {
from: 0.0.0.0/0 to: 192.168.1.0/24
command: udpreply
}

# Allow the internal network to connect to everything outside
pass {
from: 192.168.1.0/24 to: 0.0.0.0/0
protocol: tcp udp
}

# Block anything else
block {
from: 0.0.0.0/0 to: 0.0.0.0/0
log: connect error
}

</pre>
* Start the proxy server
<bash> sudo /etc/init.d/danted restart </bash>
* If you get a "Failed to open libc.so..." error message when starting the proxy server, this is caused by a [https://bugs.launchpad.net/ubuntu/+source/dante/+bug/767085 mistake] in the dante-server debian package. To work around this, create a simlink to the correct libc.so and try to start danted again.
<bash> sudo ln -sf /lib/i386-linux-gnu/libc-2.13.so /lib/i386-linux-gnu/libc.so </bash>
* Test connecting through the proxy by configuring the web browser on one of the test machines connected through the gateway to use the proxy.
* Restrict outgoing traffic through the gateway by enabling the more restrictive iptables configuration.
<bash> sudo ~/scripts/nat_block_all.sh </bash>
* In the proxy options section of the browser, supply 192.168.1.1 as the SOCKS server and 1080 as the port.
* Attempt to browse to an internet website. If you can browse as usual, the proxy is working correctly.
* Disable the proxy in the browser.

== Set up the HTTP (Web) proxy ==
=== Configure the HTTP proxy ===
* Edit /etc/squid/squid.conf. We will be editing the existing file instead of replacing it. We need to open up some ports, enable SSL communication via the CONNECT method, and disable caching.
* A patch that will give us the access we need:
<diff>
--- squid.conf.original 2011-07-11 13:58:12.640564821 -0400
+++ squid.conf 2011-08-16 15:22:55.420862811 -0400
@@ -606,8 +606,6 @@
# Example rule allowing access from your local networks.
# Adapt to list your (internal) IP networks from where browsing
# should be allowed
-acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
-acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
#
acl SSL_ports port 443 # https
@@ -628,6 +626,8 @@
acl Safe_ports port 901 # SWAT
acl purge method PURGE
acl CONNECT method CONNECT
+# Enable SSL via CONNECT
+acl SSL method CONNECT

# TAG: http_access
# Allowing or Denying access based on defined access lists
@@ -661,7 +661,8 @@
# Deny requests to unknown ports
http_access deny !Safe_ports
# Deny CONNECT to other than SSL ports
-http_access deny CONNECT !SSL_ports
+## Removed to allow connection to caps router on simhosts.
+#http_access deny CONNECT !SSL_ports
#
# We strongly recommend the following be uncommented to protect innocent
# web applications running on the proxy server who think the only
@@ -675,6 +676,8 @@
# from where browsing should be allowed
#http_access allow localnet
http_access allow localhost
+http_access allow localnet
+

# And finally deny all other access to this proxy
http_access deny all
@@ -1111,8 +1114,9 @@
# visible on the internal address.
#
# Squid normally listens to port 3128
-http_port 3128
+http_port 192.168.1.1:3128

+cache deny all
# TAG: https_port
# Note: This option is only available if Squid is rebuilt with the
# --enable-ssl option
@@ -3939,7 +3943,7 @@
# "0". May be overridden with -u on the command line.
#
#Default:
-# icp_port 3130
+icp_port 0

# TAG: htcp_port
# The port number where Squid sends and receives HTCP queries to

</diff>

* To apply the patch, save it to a file named squid.diff in your home directory and run the following command:
<bash>
sudo patch /etc/squid/squid.conf ~/squid.diff
</bash>

* If you would rather edit by hand, a sequence of instructions to do the above are listed below.1
* Look for the following line:
http_port 3128
* Replace with the following:
http_port 192.168.1.1:3128
cache deny all
* Look for the following lines:
acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network

* Replace with
acl localnet src 192.168.1.0/8 # RFC1918 possible internal network

* Look for the following line:
acl CONNECT method CONNECT
* Append two lines after to make it look like this:
acl CONNECT method CONNECT
# Enable SSL via CONNECT
acl SSL method CONNECT

* Comment out the following line:
http_access deny CONNECT !SSL_ports
* It should look like this:
#http_access deny CONNECT !SSL_ports

* Look for the following line:
http_access allow localhost
* Append another line after it so that it now looks like this:
http_access allow localhost
http_access allow localnet

* Now that the configuration file is correct, we need to restart the squid proxy:
<bash>
sudo stop squid
sudo start squid
</bash>
* Examine syslog for any errors related to squid.
<bash>
sudo tail /var/log/syslog
</bash>

=== Test the HTTP Proxy ===
* Restrict outgoing traffic through the gateway by enabling the more restrictive iptables configuration.
<bash> sudo ~/scripts/nat_block_all.sh </bash>
* In the proxy options section of the browser on the test machine, supply 192.168.1.1 as the HTTP and HTTPS proxy server with 3128 as the port in both cases.
* Remove any SOCKS proxy configuration in the browser.
* Attempt to browse to an internet website. Also try browsing to an https:// website such as [https://codereview.secondlife.com https://codereview.secondlife.com]. If you can browse as usual, the proxy is working correctly.
* Disable the proxy in the browser.

== Cleanup ==
* Reboot the machine, using the graphical menus to reboot or the following command. Verify that everything still works as before.
<bash> sudo shutdown -r now </bash>
* Note that we left the unrestricted firewall configuration as the default. When the gateway is rebooted, you will need to rerun '''~/scripts/nat_blocked_all.sh''' to restrict connections again. If you would like that to be the default state, copy '''~/scripts/nat_blocked_all.sh''' to '''/etc/init.d/nat.sh'''.

== Packet Capture Tools ==
* On a machine with the X11 graphical environment, you can use wireshark to capture packets going through the computer. Install wireshark with the following command.
<bash> sudo apt-get install wireshark </bash>
* Allow non-root users to perform captures. Note that this should not be done on a machine that you do not trust all the users to monitor traffic.
<bash> sudo setcap 'CAP_NET_RAW+eip CAP_NET_ADMIN+eip' /usr/bin/dumpcap </bash>
* Start wireshark. In the list of capture device, select "pseudo-device that captures on all interface". The program should be capturing packets.
* Use the filter box at the top to filter for specific protocols, like "http" or certain hosts with strings like "ip.addr == 192.168.1.120".

= Useful References =
If you run into difficulties with these instructions, there is more information in the official documentation. I based the configurations in this document mostly from the following sites:
*[https://help.ubuntu.com/community/Router Ubuntu Router Instructions]

User:Log Linden/Socks5Viewer/TestPlan/ProxyGateway

2012-04-30T22:40:30Z

Log Linden: /* Packet Capture Tools */

= Introduction =
These instructions will help you set up a simple Ubuntu gateway machine that will allow you to control access to the outside network for computers that are operating behind the gateway. This setup was created for testing the SOCKS 5 proxy. With some modification, the same setup could be used for testing various other network conditions, including throttling the connection speed down to something closer to residential DSL speeds. The instructions are intended for someone with a reasonable familiarity with Ubuntu Linux and will only discuss the customisations needed to set up the gateway.

= Requirements =
== Hardware ==
* A standard off-the-shelf PC with two Ethernet NICs
* 1 Ethernet switch for the "internal" network
* Network cables
* Other computers to actually test the viewer on.

== Software ==
* Ubuntu Linux 11.04 (Natty) [http://www.ubuntu.com/download/ubuntu/download install media] (Other flavors of Ubuntu, including Ubuntu server should work with these instructions as well.)

= Instructions =
== Connect network hardware ==
* Connect one network card to the outside network.
* Connect the other network card to the internal ethernet switch.
* Connect testing computers to the internal network switch.
[[File:Socks_test_setup.2.png|border|600px|SOCKS Testing Network Setup]]

== Install Ubuntu and Packages ==
* Install Ubuntu on the gateway machine. Consult the official Ubuntu install [https://help.ubuntu.com/community/GraphicalInstall instructions] for more information.
* Reboot into the installed system.
* Update the packages on the system.
<bash>
sudo apt-get update
sudo apt-get upgrade
</bash>
* Install some additional useful packages that we will need.
<bash> sudo apt-get install dnsmasq dante-server openssh </bash>
== Configure Network Interfaces ==
* IMPORTANT NOTE: For the purpose of this document, eth0 is the device that is connecting to the outside network, and eth1 is connecting to the internal network. Verify which is which on your setup.
<bash>ifconfig</bash>
Chances are, only one of the ethX devices will have been assigned an IP address by your network, this is the one connected to the external network. If this is not eth0 you need to either switch the network cables connected to the computer or remember to swap the interface names everywhere in the rest of this document. We are going to be assigning eth1 with a static IP address, which can cause problems if it conflicts with the rest of your network.
* Edit, with sudo, '/etc/network/interfaces' and replace its contents with the following
<bash>
auto lo eth0 eth1

iface lo inet loopback

# External network
iface eth0 inet dhcp

# Internal network
iface eth1 inet static
address 192.168.1.1
network 192.168.1.0
netmask 255.255.255.0
broadcast 192.168.1.255
</bash>
* This configuration makes eth0 continue to get its configuration through DHCP, and statically configures eth1. Listing both interfaces on the auto line will mean that they will automatically connect on startup.
* Because we are setting up the interfaces in this config file, we should probably prevent networkmanager from trying to do it as well.
<bash> sudo update-rc.d NetworkManager remove</bash>
* Restart the network
<bash>
sudo /etc/init.d/networking stop
sudo /etc/init.d/networking start
</bash>
* Verify the network configuration by looking for the correct IP addresses for eth0 and eth1.
<bash> ifconfig</bash>

== Set up DNS and DHCP ==
* dnsmasq is a lightweight combination DNS/DHCP server. For the anticipated number of clients for this network, it should be sufficient.
* Warning: Again, it is important to get the network interfaces correct for this. Running a rogue DHCP server on the wrong interface could cause major network problems. eth1 should be the '''internal''' network card.
* Replace /etc/dnsmasq.conf with the following:
<bash>
interface=eth1

dhcp-range=192.168.1.50,192.168.1.150,12h
dhcp-authoritative
dhcp-script=/bin/echo
</bash>
* Restart dnsmasq
<bash> sudo /etc/init.d/dnsmasq restart </bash>

== Set up the Firewall ==
* Save the following two scripts to ~/scripts
=== nat_forward_all.sh ===
<bash>
echo -e "\n\nLoading simple rc.firewall-iptables version $FWVER..\n"
DEPMOD=/sbin/depmod
MODPROBE=/sbin/modprobe

EXTIF="eth0"
INTIF="eth1"
echo " External Interface: $EXTIF"
echo " Internal Interface: $INTIF"

#======================================================================
#== No editing beyond this line is required for initial MASQ testing ==
echo -en " loading modules: "
echo " - Verifying that all kernel modules are ok"
$DEPMOD -a
echo "----------------------------------------------------------------------"
echo -en "ip_tables, "
$MODPROBE ip_tables
echo -en "nf_conntrack, "
$MODPROBE nf_conntrack
echo -en "nf_conntrack_ftp, "
$MODPROBE nf_conntrack_ftp
echo -en "nf_conntrack_irc, "
$MODPROBE nf_conntrack_irc
echo -en "iptable_nat, "
$MODPROBE iptable_nat
echo -en "nf_nat_ftp, "
$MODPROBE nf_nat_ftp
echo "----------------------------------------------------------------------"
echo -e " Done loading modules.\n"
echo " Enabling forwarding.."
echo "1" > /proc/sys/net/ipv4/ip_forward
echo " Enabling DynamicAddr.."
echo "1" > /proc/sys/net/ipv4/ip_dynaddr
echo " Clearing any existing rules and setting default policy.."https://wiki.secondlife.com/w/index.php?title=User:Log_Linden/Socks5Viewer/TestPlan/ProxyGateway

iptables-restore <<-EOF
*nat
-A POSTROUTING -o "$EXTIF" -j MASQUERADE
COMMIT
*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A FORWARD -i "$EXTIF" -o "$INTIF" -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -i "$INTIF" -o "$EXTIF" -j ACCEPT
-A FORWARD -j LOG
COMMIT
EOF

echo -e "\nrc.firewall-iptables v$FWVER done.\n"
</bash>
=== nat_block_all.sh ===
<bash>
echo -e "\n\nLoading simple rc.firewall-iptables version $FWVER..\n"
DEPMOD=/sbin/depmod
MODPROBE=/sbin/modprobe

EXTIF="eth0"
INTIF="eth1"
echo " External Interface: $EXTIF"
echo " Internal Interface: $INTIF"

#======================================================================
#== No editing beyond this line is required for initial MASQ testing ==
echo -en " loading modules: "
echo " - Verifying that all kernel modules are ok"
$DEPMOD -a
echo "----------------------------------------------------------------------"
echo -en "ip_tables, "
$MODPROBE ip_tables
echo -en "nf_conntrack, "
$MODPROBE nf_conntrack
echo -en "nf_conntrack_ftp, "
$MODPROBE nf_conntrack_ftp
echo -en "iptable_nat, "
$MODPROBE iptable_nat
echo -en "nf_nat_ftp, "
$MODPROBE nf_nat_ftp
echo "----------------------------------------------------------------------"
echo -e " Done loading modules.\n"
echo " Enabling forwarding.."
echo "1" > /proc/sys/net/ipv4/ip_forward
echo " Enabling DynamicAddr.."
echo "1" > /proc/sys/net/ipv4/ip_dynaddr
echo " Clearing any existing rules and setting default policy.."

iptables-restore <<-EOF
*nat
-A POSTROUTING -o "$EXTIF" -j MASQUERADE
COMMIT
*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A FORWARD -i "$INTIF" -j LOG
-A FORWARD -i "$INTIF" -j REJECT
COMMIT
EOF

echo -e "\nrc.firewall-iptables v$FWVER done.\n"
</bash>
* Make both scripts executable
<bash>
chmod a+x ~/scripts/nat_block_all.sh
chmod a+x ~/scripts/nat_forward_all.sh
</bash>
* Test the wide-open script. Inspect the output for errors indicating something is wrong.
<bash>
sudo ~/scripts/nat_forward_all.sh
</bash>
* If the previous command was successful and you got dns and dhcp configured before, you should be able to connect through your gateway on computers on the internal network.
* Test this now, by connecting a test computer to the network if you haven't already. Try browsing the web on one of the test machines as a quick test. Use '''ipconfig /all''' or '''ifconfig''' to see how the test computer is being configured. Expected values are below:
{| class="lltable" border="1"
|+ '''Test Machine Network Parameters'''

|--
!Parameter
!Expected Value

|--
| IP Address
| 192.168.1.50-192.168.1.150

|--
| Subnet Mask
| 255.255.255.0

|--
| Default Gateway
| 192.168.1.1

|--
| Nameserver (DNS Server)
| 192.168.1.1

|}

* If everything seems to be working correctly, make the wide-open config run during system startup.
<bash>
sudo cp nat_forward_all.sh /etc/init.d/nat.sh
sudo ln -s /etc/init.d/nat.sh /etc/rc2.d/S95masquradescript
</bash>

== Set up the SOCKS 5 proxy==
* Replace /etc/danted.conf with the following.
<pre>
logoutput: /var/log/dante.log

internal: eth1 port = 1080

external: eth0

method: username none
# Accept either username auth or no auth. If using username auth, use the same username and password that are used to sign on to this machine.

#user.privileged: proxy
user.notprivileged: nobody

### "client-rules" ###

client pass {
from: 192.168.1.0/24 port 1-65535 to: 0.0.0.0/0
}

client block {
from: 0.0.0.0/0 to: 0.0.0.0/0
log: connect error
}

### "socks-rules" ###
# Block connections to loopback interfaces
block {
from: 0.0.0.0/0 to: 127.0.0.0/8
log: connect error
}

# Allow udp reply packets from outside
pass {
from: 0.0.0.0/0 to: 192.168.1.0/24
command: udpreply
}

# Allow the internal network to connect to everything outside
pass {
from: 192.168.1.0/24 to: 0.0.0.0/0
protocol: tcp udp
}

# Block anything else
block {
from: 0.0.0.0/0 to: 0.0.0.0/0
log: connect error
}

</pre>
* Start the proxy server
<bash> sudo /etc/init.d/danted restart </bash>
* If you get a "Failed to open libc.so..." error message when starting the proxy server, this is caused by a [https://bugs.launchpad.net/ubuntu/+source/dante/+bug/767085 mistake] in the dante-server debian package. To work around this, create a simlink to the correct libc.so and try to start danted again.
<bash> sudo ln -sf /lib/i386-linux-gnu/libc-2.13.so /lib/i386-linux-gnu/libc.so </bash>
* Test connecting through the proxy by configuring the web browser on one of the test machines connected through the gateway to use the proxy.
* Restrict outgoing traffic through the gateway by enabling the more restrictive iptables configuration.
<bash> sudo ~/scripts/nat_block_all.sh </bash>
* In the proxy options section of the browser, supply 192.168.1.1 as the SOCKS server and 1080 as the port.
* Attempt to browse to an internet website. If you can browse as usual, the proxy is working correctly.
* Disable the proxy in the browser.

== Set up the HTTP (Web) proxy ==
=== Configure the HTTP proxy ===
* Edit /etc/squid/squid.conf. We will be editing the existing file instead of replacing it. We need to open up some ports, enable SSL communication via the CONNECT method, and disable caching.
* A patch that will give us the access we need:
<diff>
--- squid.conf.original 2011-07-11 13:58:12.640564821 -0400
+++ squid.conf 2011-08-16 15:22:55.420862811 -0400
@@ -606,8 +606,6 @@
# Example rule allowing access from your local networks.
# Adapt to list your (internal) IP networks from where browsing
# should be allowed
-acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
-acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
#
acl SSL_ports port 443 # https
@@ -628,6 +626,8 @@
acl Safe_ports port 901 # SWAT
acl purge method PURGE
acl CONNECT method CONNECT
+# Enable SSL via CONNECT
+acl SSL method CONNECT

# TAG: http_access
# Allowing or Denying access based on defined access lists
@@ -661,7 +661,8 @@
# Deny requests to unknown ports
http_access deny !Safe_ports
# Deny CONNECT to other than SSL ports
-http_access deny CONNECT !SSL_ports
+## Removed to allow connection to caps router on simhosts.
+#http_access deny CONNECT !SSL_ports
#
# We strongly recommend the following be uncommented to protect innocent
# web applications running on the proxy server who think the only
@@ -675,6 +676,8 @@
# from where browsing should be allowed
#http_access allow localnet
http_access allow localhost
+http_access allow localnet
+

# And finally deny all other access to this proxy
http_access deny all
@@ -1111,8 +1114,9 @@
# visible on the internal address.
#
# Squid normally listens to port 3128
-http_port 3128
+http_port 192.168.1.1:3128

+cache deny all
# TAG: https_port
# Note: This option is only available if Squid is rebuilt with the
# --enable-ssl option
@@ -3939,7 +3943,7 @@
# "0". May be overridden with -u on the command line.
#
#Default:
-# icp_port 3130
+icp_port 0

# TAG: htcp_port
# The port number where Squid sends and receives HTCP queries to

</diff>

* To apply the patch, save it to a file named squid.diff in your home directory and run the following command:
<bash>
sudo patch /etc/squid/squid.conf ~/squid.diff
</bash>

* If you would rather edit by hand, a sequence of instructions to do the above are listed below.1
* Look for the following line:
http_port 3128
* Replace with the following:
http_port 192.168.1.1:3128
cache deny all
* Look for the following lines:
acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network

* Replace with
acl localnet src 192.168.1.0/8 # RFC1918 possible internal network

* Look for the following line:
acl CONNECT method CONNECT
* Append two lines after to make it look like this:
acl CONNECT method CONNECT
# Enable SSL via CONNECT
acl SSL method CONNECT

* Comment out the following line:
http_access deny CONNECT !SSL_ports
* It should look like this:
#http_access deny CONNECT !SSL_ports

* Look for the following line:
http_access allow localhost
* Append another line after it so that it now looks like this:
http_access allow localhost
http_access allow localnet

* Now that the configuration file is correct, we need to restart the squid proxy:
<bash>
sudo stop squid
sudo start squid
</bash>
* Examine syslog for any errors related to squid.
<bash>
sudo tail /var/log/syslog
</bash>

=== Test the HTTP Proxy ===
* Restrict outgoing traffic through the gateway by enabling the more restrictive iptables configuration.
<bash> sudo ~/scripts/nat_block_all.sh </bash>
* In the proxy options section of the browser on the test machine, supply 192.168.1.1 as the HTTP and HTTPS proxy server with 3128 as the port in both cases.
* Remove any SOCKS proxy configuration in the browser.
* Attempt to browse to an internet website. Also try browsing to an https:// website such as [https://codereview.secondlife.com https://codereview.secondlife.com]. If you can browse as usual, the proxy is working correctly.
* Disable the proxy in the browser.

== Cleanup ==
* Reboot the machine, using the graphical menus to reboot or the following command. Verify that everything still works as before.
<bash> sudo shutdown -r now </bash>
* Note that we left the unrestricted firewall configuration as the default. When the gateway is rebooted, you will need to rerun '''~/scripts/nat_blocked_all.sh''' to restrict connections again. If you would like that to be the default state, copy '''~/scripts/nat_blocked_all.sh''' to '''/etc/init.d/nat.sh'''.

== Packet Capture Tools ==
* On a machine with the X11 graphical environment, you can use wireshark to capture packets going through the computer. Install wireshark with the following command.
<bash> sudo apt-get install wireshark <bash>
* Allow non-root users to perform captures. Note that this should not be done on a machine that you do not trust all the users to monitor traffic.
<bash> sudo setcap 'CAP_NET_RAW+eip CAP_NET_ADMIN+eip' /usr/bin/dumpcap </bash>
* Start wireshark. In the list of capture device, select "pseudo-device that captures on all interface". The program should be capturing packets.
* Use the filter box at the top to filter for specific protocols, like "http" or certain hosts with strings like "ip.addr == 192.168.1.120".

= Useful References =
If you run into difficulties with these instructions, there is more information in the official documentation. I based the configurations in this document mostly from the following sites:
*[https://help.ubuntu.com/community/Router Ubuntu Router Instructions]

User:Log Linden/Socks5Viewer

2011-10-26T17:42:28Z

Log Linden: /* Test Builds */

== Project Pages ==
* [https://jira.secondlife.com/browse/STORM-1112 Project Jira ]
* [https://codereview.secondlife.com/r/374/ Code Review ]
* [[/TestPlan | Test Plan ]]
== Test Builds ==
Use any current viewer, this code has been merged with viewer-development.

== Screenshots ==
===First Revision===
[[File:Socks5_old.png]] 
===Second Revision===
[[File:Socks5_new.png]] 
__NOTOC__

User:Log Linden/Socks5Viewer/TestPlan

2011-08-26T21:13:37Z

Log Linden: /* Integrated Web Browser */

[[Category:Test Scripts]]
{| cellspacing="0" cellpadding="0" style="clear: {{{clear|right}}}; margin-bottom: .5em; float: right; padding: .5em 0 .8em 1.4em; background: none; width: {{{width|{{{1|auto}}}}}};" {{*if:{{{limit|}}}|class="toclimit-{{{limit}}}"}}
| __TOC__
|}
= Scope =
* This test is to verify that newly added proxy support in the viewer works as expected.
* The user story that prompted the changes is [https://jira.secondlife.com/browse/STORM-1112 STORM-1112 ].
* This test will only be meaningful if performed in a network environment that does not have access to second life.
* The test also requires a working web proxy host and SOCKS 5 proxy host.
* Estimated running time: 3 hours/platform after securing the appropriate test environment.

= Set-up =
== Environment ==
* Viewer: This test requires a build of the viewer that contains the LLProxy code. Grab the latest for your platform from the link below:
{{ViewerInstallers|{{JiraIssue|STORM-1112|Implement SOCKS 5 proxy}}| Allow the Second Life Viewer to connect through a SOCKS 5 proxy. |task=log_viewer-socks5|repo=https://bitbucket.org/log_linden/viewer_socks5}}
* Server: The test requires testing of mesh upload and download functionality, so access to a region with mesh support is required. Agni or Aditi are each fine. Region crossing will also be tested, so adjacent regions to test in will also be required.
* A restrictive, firewalled network to connect the testing machine to is required to obtain valid test results.
* A working web proxy host and a working SOCKS 5 host are required to complete the test.
* Instructions to set up a reference Ubuntu Linux server that will act as a firewall and proxy gateway [[User:Log_Linden/Socks5Viewer/TestPlan/ProxyGateway | are available]].
* While 3rd party testers are welcome to set up a duplicate of our reference gateway server, we are also interested in results you might get in your organization's specific network setup, rather than using our reference setup. Since you might not be allowed to reconfigure your organization's firewall or proxy host, feel free to only test in the proxy configuration your organization supports and report on results you observe.

== Other ==
* You need a Second Life account that is able to upload mesh assets on the grid being tested. This will require you to have payment information on file and to pass a brief test on intellectual property rights. A tutorial to help you get set up is available in the [http://community.secondlife.com/t5/English-Knowledge-Base/Uploading-a-mesh-model/ta-p/974185 Second Life Knowledge Base].
* Your avatar should be a member of a group and be allowed to send messages in that group for testing.
* Part of the test is making sure land parcel media is functional. Find somewhere in world that has both web parcel media and video parcel media.
* Sandbox, or other area where building is allowed.
* Have a test image file, sound file, and collada model available to test upload functionality. A sample collada model is available from the [https://collada.org/owl/download.php?sess=0&parent=126&expand=1&order=name&curview=0&binary=1&id=698/ collada.org website].
* To test the gpu table and feature table download functionality of the viewer, a packet capture tool on the proxy host such as wireshark or tcp_dump is necessary to verify that the request tool is making use of the proxy. This might not be possible if you do not have access to your organization's proxy host.

= Common Procedures =
Refer to this section when asked to do one of the following in a test step.
* '''Enable proxy connection with HTTP traffic sent through web proxy.'''
** Change these settings before logging into Second Life.
** Open the Proxy settings floater. Me->Preferences->Setup->"Adjust Proxy Settings"
** Check "Use HTTP Proxy for Web pages" and enter the address and port number.
** Check "Use SOCKS 5 Proxy for UDP traffic" and enter the address and port number.
** Under other HTTP traffic proxy, select "Use HTTP Proxy".
** Click OK.

* '''Enable proxy connection with HTTP traffic sent through SOCKS 5 proxy.'''
** Change these settings before logging into Second Life.
** Open the Proxy settings floater. Me->Preferences->Setup->"Adjust Proxy Settings"
** Check "Use HTTP Proxy for Web pages" and enter the address and port number.
** Check "Use SOCKS 5 Proxy for UDP traffic" and enter the address and port number.
** Under other HTTP traffic proxy, select "Use SOCKS 5 Proxy".
** Click OK.

* '''Disable all proxies'''
** Change these settings before logging into Second Life.
** Open the Proxy settings floater. Me->Preferences->Setup->"Adjust Proxy Settings"
** Uncheck "Use HTTP Proxy for Web pages".
** Uncheck "Use SOCKS 5 Proxy for UDP traffic".
** Click OK.

* '''Clear Viewer Caches'''
** Click the "Clear Cache" button on the advanced tab of the preferences floater.
** Confirm that you want to clear the cache.
** Restart the Viewer.

= Test Steps =
== Configuration Consistency Checks ==
* '''Expected Defaults''' Check the default configuration.
** Install a version of the viewer that supports LLProxy communication.
** Start the viewer that was installed, but do not log in. If you are in Basic mode, change to Advanced and restart.
** Navigate to the proxy control floater (Me->Preferences->Setup->Adjust proxy Settings.)
** Inspect the settings.
** '''Verify''' that both proxies are disabled.
** Leave this floater open for the next test.
* '''Reset "Other HTTP traffic proxy" radio button when configuration is not possible.'''
** Enable HTTP Proxy.
** Select HTTP proxy as the "other HTTP traffic proxy".
** Disable HTTP Proxy.
** '''Verify''' that "Do not proxy." is now selected as the Other HTTP traffic Proxy.
** Enable SOCKS 5 Proxy.
** Select SOCKS 5 proxy as the "other HTTP traffic proxy".
** Disable SOCKS 5 Proxy.
** '''Verify''' that "Do not proxy." is now selected as the Other HTTP traffic Proxy.
* '''Invalid HTTP Proxy Configuration Error-Handling''' Test a configuration that asks for HTTP via SOCKS 5 when SOCKS 5 is disabled.
** Enable both proxies, enter valid information for both proxies.
** Change the "Other HTTP traffic proxy" option to "Use SOCKS 5 proxy".
** Quit the viewer.
** Edit the settings.xml file that corresponds to the channel of the viewer you are using to test with (e.g. settings_developer.xml, settings.xml, settings_beta.xml, etc.).
** Change the value of Socks5ProxyEnabled to "0".
** Restart the viewer.
** '''Verify''' that the viewer doesn't crash
** Open the proxy preferences floater.
** '''Verify''' that the "Other HTTP traffic" proxy option is now set to "Do not proxy".
** Enable the SOCKS 5 proxy, and authentication. Make other http traffic use SOCKS 5.
** Click OK and quit the viewer.
** '''Verify''' that Secondlife.log contains the following warning:
2011-08-23T01:33:25Z WARNING: LLStartUp::startLLProxy: Invalid other HTTP proxy configuration.
* '''Invalid Authentication Configuration Error-Handling.''' Test that an unexpected authentication method will not crash the viewer.
** Before starting the viewer, change the value of Socks5AuthType to "FakeAuth", a fake value.
** Start the viewer, but do not log in.
** '''Verify''' that the viewer doesn't crash.
** '''Verify''' that in the settings proxy floater, that authentication is disabled.
** Close the viewer.
** '''Verify''' that Secondlife.log contains the following warning:
2011-08-23T01:30:38Z WARNING: LLStartUp::startLLProxy: Invalid SOCKS 5 authentication type.

== Proxy Enabled, other HTTP through Web Proxy ==
* Follow the instructions above to enable the proxy and send HTTP traffic through the web proxy.
* This should be run with the firewall fully enabled to ensure the only traffic is being sent through the proxy.
* '''Verify''' that you are able to successfully log into Second Life.

=== Viewer Initialization ===
* '''HTTP Tables Loading''' Verify that the viewer is able to fetch the GPU table and feature table via the proxy.
** The proxy should be enabled before starting this test.
** Close the viewer.
** Start a packet capture on the proxy host that captures on all interfaces. Note: Even if you are unable to use packet filtering software, complete the test and verify that the error strings below are not in the log file.
** Start the viewer but do not log in.
** Inspect the capture for an HTTP request for an HTTP GET for a file of the form gpu_table.X.Y.Z.txt and for featuretable.X.Y.Z.txt.
** '''Verify''' that there was a request originating from the test machine for each of these files, and a subsequent request from the proxy host for the same files. It is normal for each of these requests to receive a 404 response.
** Close the viewer.
** Inspect the Secondlife.log file.
** '''Verify''' that there are no logs matching the following in Secondlife.log.
2011-08-18T21:42:07Z WARNING: LLURLRequest::process_impl: URLRequest Error: 56, Failure when receiving data from the peer, http://viewer-settings.secondlife.com/featuretable_xp.3.0.1.238013.txt
2011-08-18T21:42:07Z INFO: LLPumpIO::processChain: Pump generated pipe err: 'STATUS_ERROR'
2011-08-18T21:42:07Z WARNING: LLURLRequest::process_impl: URLRequest Error: 56, Failure when receiving data from the peer, http://viewer-settings.secondlife.com/gpu_table.3.0.1.238013.txt
2011-08-18T21:42:07Z INFO: LLPumpIO::processChain: Pump generated pipe err: 'STATUS_ERROR'
* '''Login Screen Renders Correctly''' The logon screen should be able to load content from the web using the configured proxy.
** Start the viewer, but do not log in.
**'''Verify''' that the contents of the login screen are displayed.

=== Avatar Navigation and Movement ===
* '''Walking'''
** '''Verify''' that your avatar can move around the world.
* '''Sitting'''
** '''Verify''' that your avatar can sit on objects.
* '''Flying'''
** '''Verify''' that you can fly around the region.
* '''World Map'''
** Open the World Map Floater (World->World Map).
** '''Verify''' that map tiles load and display the layout of the surrounding regions.
** '''Verify''' that green dots representing avatars are displayed.
** Close the World Map.
* '''Minimap'''
** Open the Mini-Map Floater (World->Mini-Map).
** '''Verify''' that map tiles are displayed.
* '''Region Crossing'''
** Fly or walk across a region boundary.
** '''Verify''' that you successfully arrive in the other region.
* '''Intra-region teleport'''
** Teleport by double clicking in the World Map floater, within the current region.
** '''Verify''' that you arrive in the place you clicked.
* '''Inter-region teleport'''
** Teleport by double clicking in the World Map floater, somewhere other than the current region.
** '''Verify''' that you arrive in the new region.

=== Avatar Communication ===
* '''Local Chat'''
** Try sending messages to others avatars standing nearby.
** '''Verify''' that the other people receive your messages
** '''Verify''' that you can receive messages from other people.
* '''Group Chat'''
** Try sending messages to a group chat channel.
** '''Verify''' that you can send messages
** '''Verify''' that you are receiving group chat messages.
* '''IM'''
** Try sending private IM messages to another avatar.
** '''Verify''' that the other avatar receives your messages
** '''Verify''' that you are able to receive their response.
* '''Display Names'''
** '''Verify''' that custom display names are visible for avatars that have them set.
** '''Verify''' that the display names of avatars are visible in your friends list.

=== Asset Download Tests ===
* Before starting this test, clear your viewer cache and relog.
* '''Texture'''
** '''Verify''' that textures load onto surfaces in your view.
* '''Sounds'''
** Locate the Button_click_down asset in your inventory. Double click the sound to play it.
** '''Verify''' that the sound plays.
* '''Notecard'''
** Locate the Community Standards notecard in the Library of your inventory.
** '''Verify''' that the notecard loads and is readable.
* '''Gestures'''
** Select a gesture from the "Gesture" menu at the bottom of the window.
** '''Verify''' that the gesture plays.
* '''Mesh'''
** Travel to a region with mesh assets available.
** '''Verify''' that the mesh assets rez and are visible.
* '''Legacy Fetch Methods'''
** Enable the Develop menu if you haven't already. (Me->Preferences->Advanced->Show Developer Menu)
** Disable HTTP Inventory and HTTP Textures in the Develop menu.
** Clear the viewer cache.
** Log back into Second Life.
** '''Verify''' that textures load onto surfaces in your view.
** '''Verify''' that your inventory loads.
** Re-enable HTTP Textures and HTTP inventory.
** Log out and back in for the next test.

=== Asset Creation Tests ===
* Move to a region where you have permission to build.

* '''Sound'''
** Upload a test sound using the upload tool (Build->Upload->Sound)
** When the upload is complete, double click the sound in your inventory to play it back.
** '''Verify''' that the sound plays.
* '''Notecard'''
** In the inventory sidebar, click the "plus sign" (+) button at the bottom of the list of assets.
** In the menu that appears, select "New Notecard".
** Add some text in the body of the notecard and click save.
** Close the notecard
** Reopen the notecard from your inventory.
** '''Verify''' that the notecard text loads.
* '''Mesh'''
** Move to a mesh-enabled region.
** Select Build->Upload->Model to start the mesh upload process.
** In the file selection dialog, select the mesh object you prepared while setting up. The example file is named duck.dae.
** Select "Calculate weights & fee" at the bottom of the Upload Model dialog.
** After the upload fee has been calculated, select the "Upload" button.
** '''Verify''' that the mesh object is added to your inventory.
** Drag the mesh object out of your inventory onto the ground to rez it.
** '''Verify''' that the mesh object is rezzed.
* '''Object Creation'''
** Create a simple object using the build tools.
** '''Verify''' that the object is created
** '''Verify''' that you can take a copy of the created object into your inventory.
** Drop the object back into the world for the next test.
* '''Texture'''
** Upload a test image using the upload tool (Build->Upload->Image).
** When the upload is complete, apply that texture to the object you created.
** '''Verify''' that the image uploaded successfully.
* '''Scripting'''
** Right click the object you created in the previous test and select edit.
** Select the content tab of the build floater.
** Click the New Script button.
** Double click the new script to edit.
** Edit the string "Hello, Avatar!" to be "Hi, Avatar!"
** Click save
** '''Verify''' that the script compiles.
** '''Verify''' that the object has sent the message "Hi, Avatar!".

=== Integrated Web Browser ===
* '''Browsing Test''' The integrated webkit browser should be able to browse while accessing the internet through a proxy.
** Enable the built-in browser. (Me->Preferences->Setup->"Use built-in browser", under "Web:").
** Enter a full url, like http://secondlife.com into text chat and send.
** Click the link in the text chat window.
** '''Verify''' that the built-in browser is able to access web content.

=== Media on a Prim ===
* '''Web Media'''
** '''Verify''' that web media is visible.
* '''Video Media'''
** '''Verify''' that video media is visible.

== Proxy Enabled, other HTTP through SOCKS 5 Proxy ==
* '''Repeat Connectivity Tests''' Verify that sending other HTTP traffic through the SOCKS 5 proxy works correctly.
** Configure the viewer as described in the '''Enable proxy connection with HTTP traffic sent through SOCKS 5 proxy.''' section above.
** '''Verify'' that you are able to successfully log into Second Life.
** Rerun the following list of test cases, which are described in the section above.
*** Viewer Initialization
*** Avatar Navigation and Movement
*** Avatar Communication
*** Asset Download Tests
*** Asset Upload Tests
*** Integrated Web Browser
*** Media On a Prim
** '''Verify''' that all tests pass.

== No Proxy Enabled ==
* '''Repeat Connectivity Tests''' Verify that users that are not using the proxy will not be negatively impacted by the change.
** Either test on another computer that is not firewalled, or relax the firewall restrictions on the testing network. If using the reference gateway configuration, run the ''nat_forward_all.sh'' script to allow traffic through without going through a proxy.
** Disable the proxy as described above.
** Rerun the following list of test cases, which are described in the section above.
*** Viewer Initialization
*** Avatar Navigation and Movement
*** Avatar Communication
*** Asset Download Tests
*** Asset Upload Tests
*** Integrated Web Browser
*** Media On a Prim
** '''Verify''' that all tests pass.
** '''Verify''' that overall viewer performance is approximately the same as usual for the machine you are testing on.
** Re-enable the firewall if you disabled it before further testing.

== SOCKS 5 with Username/Password Authentication ==
* '''Successful Login with SOCKS Authentication''' Test that the viewer can connect when the SOCKS 5 host requires a password.
** Enable both proxies, with "other" traffic going through SOCKS 5.
** Also in the proxy settings floater, select Username/Password as the SOCKS Authentication method.
** Enter your SOCKS 5 username and password in the appropriate fields. If you followed the reference gateway instructions, your linux username and password should work for the socks credentials.
** Select OK.
** Try to log in to Second Life.
** '''Verify''' that login is successful.
** Leave authentication enabled for the next test.
** Optional: The previous set of connectivity tests could be run in this mode as well to verify that the Username/Password authentication method works as well. This is a lower priority than the other three modes because this configuration is behaviorally very similar to the no authentication test, and should either connect or not connect.
* '''SOCKS 5 Password Security''' The SOCKS 5 password should not be stored in cleartext.
** Leave SOCKS 5 authentication enabled in the viewer from the previous test.
** Close all running instances of the viewer.
** Navigate to the user's Second Life settings directory.
** Search, using grep or ctrl-f in notepad depending on the platform, for the username and password you used to connect to the SOCKS 5 server in the previous step in the settings.xml that corresponds to the viewer version you are testing with (settings.xml if using a release version, settings_development.xml if using a development build, etc).
** '''Verify''' that the username and password do not appear in the settings files.
** Start the viewer and disable authentication.

----


= Pass/Fail Criteria =
* '''Passes''' if
** No unexpected behaviors are observed
* '''Fails''' if
** Deviation from expected behavior is observed
** A bug is detected that was not accounted for by this test plan
** Performance degradation is observed when the proxy is disabled.
* '''Known Issues'''
** SLVoice does not support proxies, therefore voice is not expected to work when running the viewer behind a strict firewall that blocks the ports used for voice communication. If voice is enabled, an error message will appear when the viewer fails to connect to the voice server.

= Tear Down =
* Disable all proxies in the viewer configuration.
* Disable the built-in browser.

User:Log Linden/Socks5Viewer/TestPlan

2011-08-26T21:13:02Z

Log Linden: Reordered object creation tests to ease testing flow.

User:Log Linden/Socks5Viewer/TestPlan

2011-08-23T01:51:43Z

Log Linden: Added check to make sure the other HTTP proxy radio button resets when the selected proxy type becomes disabled.

[[Category:Test Scripts]]
{| cellspacing="0" cellpadding="0" style="clear: {{{clear|right}}}; margin-bottom: .5em; float: right; padding: .5em 0 .8em 1.4em; background: none; width: {{{width|{{{1|auto}}}}}};" {{*if:{{{limit|}}}|class="toclimit-{{{limit}}}"}}
| __TOC__
|}
= Scope =
* This test is to verify that newly added proxy support in the viewer works as expected.
* The user story that prompted the changes is [https://jira.secondlife.com/browse/STORM-1112 STORM-1112 ].
* This test will only be meaningful if performed in a network environment that does not have access to second life.
* The test also requires a working web proxy host and SOCKS 5 proxy host.
* Estimated running time: 3 hours/platform after securing the appropriate test environment.

= Set-up =
== Environment ==
* Viewer: This test requires a build of the viewer that contains the LLProxy code. Grab the latest for your platform from the link below:
{{ViewerInstallers|{{JiraIssue|STORM-1112|Implement SOCKS 5 proxy}}| Allow the Second Life Viewer to connect through a SOCKS 5 proxy. |task=log_viewer-socks5|repo=https://bitbucket.org/log_linden/viewer_socks5}}
* Server: The test requires testing of mesh upload and download functionality, so access to a region with mesh support is required. Agni or Aditi are each fine. Region crossing will also be tested, so adjacent regions to test in will also be required.
* A restrictive, firewalled network to connect the testing machine to is required to obtain valid test results.
* A working web proxy host and a working SOCKS 5 host are required to complete the test.
* Instructions to set up a reference Ubuntu Linux server that will act as a firewall and proxy gateway [[User:Log_Linden/Socks5Viewer/TestPlan/ProxyGateway | are available]].
* While 3rd party testers are welcome to set up a duplicate of our reference gateway server, we are also interested in results you might get in your organization's specific network setup, rather than using our reference setup. Since you might not be allowed to reconfigure your organization's firewall or proxy host, feel free to only test in the proxy configuration your organization supports and report on results you observe.

== Other ==
* You need a Second Life account that is able to upload mesh assets on the grid being tested. This will require you to have payment information on file and to pass a brief test on intellectual property rights. A tutorial to help you get set up is available in the [http://community.secondlife.com/t5/English-Knowledge-Base/Uploading-a-mesh-model/ta-p/974185 Second Life Knowledge Base].
* Your avatar should be a member of a group and be allowed to send messages in that group for testing.
* Part of the test is making sure land parcel media is functional. Find somewhere in world that has both web parcel media and video parcel media.
* Sandbox, or other area where building is allowed.
* Have a test image file, sound file, and collada model available to test upload functionality. A sample collada model is available from the [https://collada.org/owl/download.php?sess=0&parent=126&expand=1&order=name&curview=0&binary=1&id=698/ collada.org website].
* To test the gpu table and feature table download functionality of the viewer, a packet capture tool on the proxy host such as wireshark or tcp_dump is necessary to verify that the request tool is making use of the proxy. This might not be possible if you do not have access to your organization's proxy host.

= Common Procedures =
Refer to this section when asked to do one of the following in a test step.
* '''Enable proxy connection with HTTP traffic sent through web proxy.'''
** Change these settings before logging into Second Life.
** Open the Proxy settings floater. Me->Preferences->Setup->"Adjust Proxy Settings"
** Check "Use HTTP Proxy for Web pages" and enter the address and port number.
** Check "Use SOCKS 5 Proxy for UDP traffic" and enter the address and port number.
** Under other HTTP traffic proxy, select "Use HTTP Proxy".
** Click OK.

* '''Enable proxy connection with HTTP traffic sent through SOCKS 5 proxy.'''
** Change these settings before logging into Second Life.
** Open the Proxy settings floater. Me->Preferences->Setup->"Adjust Proxy Settings"
** Check "Use HTTP Proxy for Web pages" and enter the address and port number.
** Check "Use SOCKS 5 Proxy for UDP traffic" and enter the address and port number.
** Under other HTTP traffic proxy, select "Use SOCKS 5 Proxy".
** Click OK.

* '''Disable all proxies'''
** Change these settings before logging into Second Life.
** Open the Proxy settings floater. Me->Preferences->Setup->"Adjust Proxy Settings"
** Uncheck "Use HTTP Proxy for Web pages".
** Uncheck "Use SOCKS 5 Proxy for UDP traffic".
** Click OK.

* '''Clear Viewer Caches'''
** Click the "Clear Cache" button on the advanced tab of the preferences floater.
** Confirm that you want to clear the cache.
** Restart the Viewer.

= Test Steps =
== Configuration Consistency Checks ==
* '''Expected Defaults''' Check the default configuration.
** Install a version of the viewer that supports LLProxy communication.
** Start the viewer that was installed, but do not log in. If you are in Basic mode, change to Advanced and restart.
** Navigate to the proxy control floater (Me->Preferences->Setup->Adjust proxy Settings.)
** Inspect the settings.
** '''Verify''' that both proxies are disabled.
** Leave this floater open for the next test.
* '''Reset "Other HTTP traffic proxy" radio button when configuration is not possible.'''
** Enable HTTP Proxy.
** Select HTTP proxy as the "other HTTP traffic proxy".
** Disable HTTP Proxy.
** '''Verify''' that "Do not proxy." is now selected as the Other HTTP traffic Proxy.
** Enable SOCKS 5 Proxy.
** Select SOCKS 5 proxy as the "other HTTP traffic proxy".
** Disable SOCKS 5 Proxy.
** '''Verify''' that "Do not proxy." is now selected as the Other HTTP traffic Proxy.
* '''Invalid HTTP Proxy Configuration Error-Handling''' Test a configuration that asks for HTTP via SOCKS 5 when SOCKS 5 is disabled.
** Enable both proxies, enter valid information for both proxies.
** Change the "Other HTTP traffic proxy" option to "Use SOCKS 5 proxy".
** Quit the viewer.
** Edit the settings.xml file that corresponds to the channel of the viewer you are using to test with (e.g. settings_developer.xml, settings.xml, settings_beta.xml, etc.).
** Change the value of Socks5ProxyEnabled to "0".
** Restart the viewer.
** '''Verify''' that the viewer doesn't crash
** Open the proxy preferences floater.
** '''Verify''' that the "Other HTTP traffic" proxy option is now set to "Do not proxy".
** Enable the SOCKS 5 proxy, and authentication. Make other http traffic use SOCKS 5.
** Click OK and quit the viewer.
** '''Verify''' that Secondlife.log contains the following warning:
2011-08-23T01:33:25Z WARNING: LLStartUp::startLLProxy: Invalid other HTTP proxy configuration.
* '''Invalid Authentication Configuration Error-Handling.''' Test that an unexpected authentication method will not crash the viewer.
** Before starting the viewer, change the value of Socks5AuthType to "FakeAuth", a fake value.
** Start the viewer, but do not log in.
** '''Verify''' that the viewer doesn't crash.
** '''Verify''' that in the settings proxy floater, that authentication is disabled.
** Close the viewer.
** '''Verify''' that Secondlife.log contains the following warning:
2011-08-23T01:30:38Z WARNING: LLStartUp::startLLProxy: Invalid SOCKS 5 authentication type.

== Proxy Enabled, other HTTP through Web Proxy ==
* Follow the instructions above to enable the proxy and send HTTP traffic through the web proxy.
* This should be run with the firewall fully enabled to ensure the only traffic is being sent through the proxy.
* '''Verify''' that you are able to successfully log into Second Life.

=== Viewer Initialization ===
* '''HTTP Tables Loading''' Verify that the viewer is able to fetch the GPU table and feature table via the proxy.
** The proxy should be enabled before starting this test.
** Close the viewer.
** Start a packet capture on the proxy host that captures on all interfaces. Note: Even if you are unable to use packet filtering software, complete the test and verify that the error strings below are not in the log file.
** Start the viewer but do not log in.
** Inspect the capture for an HTTP request for an HTTP GET for a file of the form gpu_table.X.Y.Z.txt and for featuretable.X.Y.Z.txt.
** '''Verify''' that there was a request originating from the test machine for each of these files, and a subsequent request from the proxy host for the same files. It is normal for each of these requests to receive a 404 response.
** Close the viewer.
** Inspect the Secondlife.log file.
** '''Verify''' that there are no logs matching the following in Secondlife.log.
2011-08-18T21:42:07Z WARNING: LLURLRequest::process_impl: URLRequest Error: 56, Failure when receiving data from the peer, http://viewer-settings.secondlife.com/featuretable_xp.3.0.1.238013.txt
2011-08-18T21:42:07Z INFO: LLPumpIO::processChain: Pump generated pipe err: 'STATUS_ERROR'
2011-08-18T21:42:07Z WARNING: LLURLRequest::process_impl: URLRequest Error: 56, Failure when receiving data from the peer, http://viewer-settings.secondlife.com/gpu_table.3.0.1.238013.txt
2011-08-18T21:42:07Z INFO: LLPumpIO::processChain: Pump generated pipe err: 'STATUS_ERROR'
* '''Login Screen Renders Correctly''' The logon screen should be able to load content from the web using the configured proxy.
** Start the viewer, but do not log in.
**'''Verify''' that the contents of the login screen are displayed.

=== Avatar Navigation and Movement ===
* '''Walking'''
** '''Verify''' that your avatar can move around the world.
* '''Sitting'''
** '''Verify''' that your avatar can sit on objects.
* '''Flying'''
** '''Verify''' that you can fly around the region.
* '''World Map'''
** Open the World Map Floater (World->World Map).
** '''Verify''' that map tiles load and display the layout of the surrounding regions.
** '''Verify''' that green dots representing avatars are displayed.
** Close the World Map.
* '''Minimap'''
** Open the Mini-Map Floater (World->Mini-Map).
** '''Verify''' that map tiles are displayed.
* '''Region Crossing'''
** Fly or walk across a region boundary.
** '''Verify''' that you successfully arrive in the other region.
* '''Intra-region teleport'''
** Teleport by double clicking in the World Map floater, within the current region.
** '''Verify''' that you arrive in the place you clicked.
* '''Inter-region teleport'''
** Teleport by double clicking in the World Map floater, somewhere other than the current region.
** '''Verify''' that you arrive in the new region.

=== Avatar Communication ===
* '''Local Chat'''
** Try sending messages to others avatars standing nearby.
** '''Verify''' that the other people receive your messages
** '''Verify''' that you can receive messages from other people.
* '''Group Chat'''
** Try sending messages to a group chat channel.
** '''Verify''' that you can send messages
** '''Verify''' that you are receiving group chat messages.
* '''IM'''
** Try sending private IM messages to another avatar.
** '''Verify''' that the other avatar receives your messages
** '''Verify''' that you are able to receive their response.
* '''Display Names'''
** '''Verify''' that custom display names are visible for avatars that have them set.
** '''Verify''' that the display names of avatars are visible in your friends list.

=== Asset Download Tests ===
* Before starting this test, clear your viewer cache and relog.
* '''Texture'''
** '''Verify''' that textures load onto surfaces in your view.
* '''Sounds'''
** Locate the Button_click_down asset in your inventory. Double click the sound to play it.
** '''Verify''' that the sound plays.
* '''Notecard'''
** Locate the Community Standards notecard in the Library of your inventory.
** '''Verify''' that the notecard loads and is readable.
* '''Gestures'''
** Select a gesture from the "Gesture" menu at the bottom of the window.
** '''Verify''' that the gesture plays.
* '''Mesh'''
** Travel to a region with mesh assets available.
** '''Verify''' that the mesh assets rez and are visible.
* '''Legacy Fetch Methods'''
** Enable the Develop menu if you haven't already. (Me->Preferences->Advanced->Show Developer Menu)
** Disable HTTP Inventory and HTTP Textures in the Develop menu.
** Clear the viewer cache.
** Log back into Second Life.
** '''Verify''' that textures load onto surfaces in your view.
** '''Verify''' that your inventory loads.
** Re-enable HTTP Textures and HTTP inventory.
** Log out and back in for the next test.

=== Asset Creation Tests ===
* Move to a region where you have permission to build.
* '''Texture'''
** Upload a test image using the upload tool (Build->Upload->Image).
** When the upload is complete, apply that texture to an object.
** '''Verify''' that the image uploaded successfully.
* '''Sound'''
** Upload a test sound using the upload tool (Build->Upload->Sound)
** When the upload is complete, double click the sound in your inventory to play it back.
** '''Verify''' that the sound plays.
* '''Notecard'''
** In the inventory sidebar, click the "plus sign" (+) button at the bottom of the list of assets.
** In the menu that appears, select "New Notecard".
** Add some text in the body of the notecard and click save.
** Close the notecard
** Reopen the notecard from your inventory.
** '''Verify''' that the notecard text loads.
* '''Mesh'''
** Move to a mesh-enabled region.
** Select Build->Upload->Model to start the mesh upload process.
** In the file selection dialog, select the mesh object you prepared while setting up. The example file is named duck.dae.
** Select "Calculate weights & fee" at the bottom of the Upload Model dialog.
** After the upload fee has been calculated, select the "Upload" button.
** '''Verify''' that the mesh object is added to your inventory.
** Drag the mesh object out of your inventory onto the ground to rez it.
** '''Verify''' that the mesh object is rezzed.
* '''Object Creation'''
** Create a simple object using the build tools.
** '''Verify''' that the object is created
** '''Verify''' that you can take a copy of the created object into your inventory.
* '''Scripting'''
** Right click the object you created in the previous test and select edit.
** Select the content tab of the build floater.
** Click the New Script button.
** Double click the new script to edit.
** Edit the string "Hello, Avatar!" to be "Hi, Avatar!"
** Click save
** '''Verify''' that the script compiles.
** '''Verify''' that the object has sent the message "Hi, Avatar!".

=== Integrated Web Browser ===
* '''Browsing Test''' The integrated webkit browser should be able to browse while accessing the internet through a proxy.
** Enable the built-in browser. (Me->Preferences->Setup->"Use built-in browser", under "Web:").
** Enter a full url, like http://secondlife.com into text chat and send.
** Click the link in the text chat window.
** '''Verify''' that the built-in browser is able to access web content.

=== Media on a Prim ===
* '''Web Media'''
** '''Verify''' that web media is visible.
* '''Video Media'''
** '''Verify''' that video media is visible.

== Proxy Enabled, other HTTP through SOCKS 5 Proxy ==
* '''Repeat Connectivity Tests''' Verify that sending other HTTP traffic through the SOCKS 5 proxy works correctly.
** Configure the viewer as described in the '''Enable proxy connection with HTTP traffic sent through SOCKS 5 proxy.''' section above.
** '''Verify'' that you are able to successfully log into Second Life.
** Rerun the following list of test cases, which are described in the section above.
*** Viewer Initialization
*** Avatar Navigation and Movement
*** Avatar Communication
*** Asset Download Tests
*** Asset Upload Tests
*** Integrated Web Browser
*** Media On a Prim
** '''Verify''' that all tests pass.

== No Proxy Enabled ==
* '''Repeat Connectivity Tests''' Verify that users that are not using the proxy will not be negatively impacted by the change.
** Either test on another computer that is not firewalled, or relax the firewall restrictions on the testing network. If using the reference gateway configuration, run the ''nat_forward_all.sh'' script to allow traffic through without going through a proxy.
** Disable the proxy as described above.
** Rerun the following list of test cases, which are described in the section above.
*** Viewer Initialization
*** Avatar Navigation and Movement
*** Avatar Communication
*** Asset Download Tests
*** Asset Upload Tests
*** Integrated Web Browser
*** Media On a Prim
** '''Verify''' that all tests pass.
** '''Verify''' that overall viewer performance is approximately the same as usual for the machine you are testing on.
** Re-enable the firewall if you disabled it before further testing.

== SOCKS 5 with Username/Password Authentication ==
* '''Successful Login with SOCKS Authentication''' Test that the viewer can connect when the SOCKS 5 host requires a password.
** Enable both proxies, with "other" traffic going through SOCKS 5.
** Also in the proxy settings floater, select Username/Password as the SOCKS Authentication method.
** Enter your SOCKS 5 username and password in the appropriate fields. If you followed the reference gateway instructions, your linux username and password should work for the socks credentials.
** Select OK.
** Try to log in to Second Life.
** '''Verify''' that login is successful.
** Leave authentication enabled for the next test.
** Optional: The previous set of connectivity tests could be run in this mode as well to verify that the Username/Password authentication method works as well. This is a lower priority than the other three modes because this configuration is behaviorally very similar to the no authentication test, and should either connect or not connect.
* '''SOCKS 5 Password Security''' The SOCKS 5 password should not be stored in cleartext.
** Leave SOCKS 5 authentication enabled in the viewer from the previous test.
** Close all running instances of the viewer.
** Navigate to the user's Second Life settings directory.
** Search, using grep or ctrl-f in notepad depending on the platform, for the username and password you used to connect to the SOCKS 5 server in the previous step in the settings.xml that corresponds to the viewer version you are testing with (settings.xml if using a release version, settings_development.xml if using a development build, etc).
** '''Verify''' that the username and password do not appear in the settings files.
** Start the viewer and disable authentication.

----


= Pass/Fail Criteria =
* '''Passes''' if
** No unexpected behaviors are observed
* '''Fails''' if
** Deviation from expected behavior is observed
** A bug is detected that was not accounted for by this test plan
** Performance degradation is observed when the proxy is disabled.
* '''Known Issues'''
** SLVoice does not support proxies, therefore voice is not expected to work when running the viewer behind a strict firewall that blocks the ports used for voice communication. If voice is enabled, an error message will appear when the viewer fails to connect to the voice server.

= Tear Down =
* Disable all proxies in the viewer configuration.
* Disable the built-in browser.

User:Log Linden/Socks5Viewer/TestPlan

2011-08-23T01:43:57Z

Log Linden: Fixes to test steps from the first runthrough of the test plan.

[[Category:Test Scripts]]
{| cellspacing="0" cellpadding="0" style="clear: {{{clear|right}}}; margin-bottom: .5em; float: right; padding: .5em 0 .8em 1.4em; background: none; width: {{{width|{{{1|auto}}}}}};" {{*if:{{{limit|}}}|class="toclimit-{{{limit}}}"}}
| __TOC__
|}
= Scope =
* This test is to verify that newly added proxy support in the viewer works as expected.
* The user story that prompted the changes is [https://jira.secondlife.com/browse/STORM-1112 STORM-1112 ].
* This test will only be meaningful if performed in a network environment that does not have access to second life.
* The test also requires a working web proxy host and SOCKS 5 proxy host.
* Estimated running time: 3 hours/platform after securing the appropriate test environment.

= Set-up =
== Environment ==
* Viewer: This test requires a build of the viewer that contains the LLProxy code. Grab the latest for your platform from the link below:
{{ViewerInstallers|{{JiraIssue|STORM-1112|Implement SOCKS 5 proxy}}| Allow the Second Life Viewer to connect through a SOCKS 5 proxy. |task=log_viewer-socks5|repo=https://bitbucket.org/log_linden/viewer_socks5}}
* Server: The test requires testing of mesh upload and download functionality, so access to a region with mesh support is required. Agni or Aditi are each fine. Region crossing will also be tested, so adjacent regions to test in will also be required.
* A restrictive, firewalled network to connect the testing machine to is required to obtain valid test results.
* A working web proxy host and a working SOCKS 5 host are required to complete the test.
* Instructions to set up a reference Ubuntu Linux server that will act as a firewall and proxy gateway [[User:Log_Linden/Socks5Viewer/TestPlan/ProxyGateway | are available]].
* While 3rd party testers are welcome to set up a duplicate of our reference gateway server, we are also interested in results you might get in your organization's specific network setup, rather than using our reference setup. Since you might not be allowed to reconfigure your organization's firewall or proxy host, feel free to only test in the proxy configuration your organization supports and report on results you observe.

== Other ==
* You need a Second Life account that is able to upload mesh assets on the grid being tested. This will require you to have payment information on file and to pass a brief test on intellectual property rights. A tutorial to help you get set up is available in the [http://community.secondlife.com/t5/English-Knowledge-Base/Uploading-a-mesh-model/ta-p/974185 Second Life Knowledge Base].
* Your avatar should be a member of a group and be allowed to send messages in that group for testing.
* Part of the test is making sure land parcel media is functional. Find somewhere in world that has both web parcel media and video parcel media.
* Sandbox, or other area where building is allowed.
* Have a test image file, sound file, and collada model available to test upload functionality. A sample collada model is available from the [https://collada.org/owl/download.php?sess=0&parent=126&expand=1&order=name&curview=0&binary=1&id=698/ collada.org website].
* To test the gpu table and feature table download functionality of the viewer, a packet capture tool on the proxy host such as wireshark or tcp_dump is necessary to verify that the request tool is making use of the proxy. This might not be possible if you do not have access to your organization's proxy host.

= Common Procedures =
Refer to this section when asked to do one of the following in a test step.
* '''Enable proxy connection with HTTP traffic sent through web proxy.'''
** Change these settings before logging into Second Life.
** Open the Proxy settings floater. Me->Preferences->Setup->"Adjust Proxy Settings"
** Check "Use HTTP Proxy for Web pages" and enter the address and port number.
** Check "Use SOCKS 5 Proxy for UDP traffic" and enter the address and port number.
** Under other HTTP traffic proxy, select "Use HTTP Proxy".
** Click OK.

* '''Enable proxy connection with HTTP traffic sent through SOCKS 5 proxy.'''
** Change these settings before logging into Second Life.
** Open the Proxy settings floater. Me->Preferences->Setup->"Adjust Proxy Settings"
** Check "Use HTTP Proxy for Web pages" and enter the address and port number.
** Check "Use SOCKS 5 Proxy for UDP traffic" and enter the address and port number.
** Under other HTTP traffic proxy, select "Use SOCKS 5 Proxy".
** Click OK.

* '''Disable all proxies'''
** Change these settings before logging into Second Life.
** Open the Proxy settings floater. Me->Preferences->Setup->"Adjust Proxy Settings"
** Uncheck "Use HTTP Proxy for Web pages".
** Uncheck "Use SOCKS 5 Proxy for UDP traffic".
** Click OK.

* '''Clear Viewer Caches'''
** Click the "Clear Cache" button on the advanced tab of the preferences floater.
** Confirm that you want to clear the cache.
** Restart the Viewer.

= Test Steps =
== Configuration Consistency Checks ==
* '''Expected Defaults''' Check the default configuration.
** Install a version of the viewer that supports LLProxy communication.
** Start the viewer that was installed, but do not log in. If you are in Basic mode, change to Advanced and restart.
** Navigate to the proxy control floater (Me->Preferences->Setup->Adjust proxy Settings.)
** Inspect the settings.
** '''Verify''' that both proxies are disabled.
** Leave this floater open for the next test.
* '''Invalid HTTP Proxy Configuration Error-Handling''' Test HTTP via socks when socks is disabled.
** Enable both proxies, enter valid information for both proxies.
** Change the "Other HTTP traffic proxy" option to "Use SOCKS 5 proxy".
** Quit the viewer.
** Edit the settings.xml file that corresponds to the channel of the viewer you are using to test with (e.g. settings_developer.xml, settings.xml, settings_beta.xml, etc.).
** Change the value of Socks5ProxyEnabled to "0".
** Restart the viewer.
** '''Verify''' that the viewer doesn't crash
** Open the proxy preferences floater.
** '''Verify''' that the "Other HTTP traffic" proxy option is now set to "Do not proxy".
** Enable the SOCKS 5 proxy, and authentication. Make other http traffic use SOCKS 5.
** Click OK and quit the viewer.
** '''Verify''' that Secondlife.log contains the following warning:
2011-08-23T01:33:25Z WARNING: LLStartUp::startLLProxy: Invalid other HTTP proxy configuration.
* '''Invalid Authentication Configuration Error-Handling.''' Test that an unexpected authentication method will not crash the viewer.
** Before starting the viewer, change the value of Socks5AuthType to "FakeAuth", a fake value.
** Start the viewer, but do not log in.
** '''Verify''' that the viewer doesn't crash.
** '''Verify''' that in the settings proxy floater, that authentication is disabled.
** Close the viewer.
** '''Verify''' that Secondlife.log contains the following warning:
2011-08-23T01:30:38Z WARNING: LLStartUp::startLLProxy: Invalid SOCKS 5 authentication type.

== Proxy Enabled, other HTTP through Web Proxy ==
* Follow the instructions above to enable the proxy and send HTTP traffic through the web proxy.
* This should be run with the firewall fully enabled to ensure the only traffic is being sent through the proxy.
* '''Verify''' that you are able to successfully log into Second Life.

=== Viewer Initialization ===
* '''HTTP Tables Loading''' Verify that the viewer is able to fetch the GPU table and feature table via the proxy.
** The proxy should be enabled before starting this test.
** Close the viewer.
** Start a packet capture on the proxy host that captures on all interfaces. Note: Even if you are unable to use packet filtering software, complete the test and verify that the error strings below are not in the log file.
** Start the viewer but do not log in.
** Inspect the capture for an HTTP request for an HTTP GET for a file of the form gpu_table.X.Y.Z.txt and for featuretable.X.Y.Z.txt.
** '''Verify''' that there was a request originating from the test machine for each of these files, and a subsequent request from the proxy host for the same files. It is normal for each of these requests to receive a 404 response.
** Close the viewer.
** Inspect the Secondlife.log file.
** '''Verify''' that there are no logs matching the following in Secondlife.log.
2011-08-18T21:42:07Z WARNING: LLURLRequest::process_impl: URLRequest Error: 56, Failure when receiving data from the peer, http://viewer-settings.secondlife.com/featuretable_xp.3.0.1.238013.txt
2011-08-18T21:42:07Z INFO: LLPumpIO::processChain: Pump generated pipe err: 'STATUS_ERROR'
2011-08-18T21:42:07Z WARNING: LLURLRequest::process_impl: URLRequest Error: 56, Failure when receiving data from the peer, http://viewer-settings.secondlife.com/gpu_table.3.0.1.238013.txt
2011-08-18T21:42:07Z INFO: LLPumpIO::processChain: Pump generated pipe err: 'STATUS_ERROR'
* '''Login Screen Renders Correctly''' The logon screen should be able to load content from the web using the configured proxy.
** Start the viewer, but do not log in.
**'''Verify''' that the contents of the login screen are displayed.

=== Avatar Navigation and Movement ===
* '''Walking'''
** '''Verify''' that your avatar can move around the world.
* '''Sitting'''
** '''Verify''' that your avatar can sit on objects.
* '''Flying'''
** '''Verify''' that you can fly around the region.
* '''World Map'''
** Open the World Map Floater (World->World Map).
** '''Verify''' that map tiles load and display the layout of the surrounding regions.
** '''Verify''' that green dots representing avatars are displayed.
** Close the World Map.
* '''Minimap'''
** Open the Mini-Map Floater (World->Mini-Map).
** '''Verify''' that map tiles are displayed.
* '''Region Crossing'''
** Fly or walk across a region boundary.
** '''Verify''' that you successfully arrive in the other region.
* '''Intra-region teleport'''
** Teleport by double clicking in the World Map floater, within the current region.
** '''Verify''' that you arrive in the place you clicked.
* '''Inter-region teleport'''
** Teleport by double clicking in the World Map floater, somewhere other than the current region.
** '''Verify''' that you arrive in the new region.

=== Avatar Communication ===
* '''Local Chat'''
** Try sending messages to others avatars standing nearby.
** '''Verify''' that the other people receive your messages
** '''Verify''' that you can receive messages from other people.
* '''Group Chat'''
** Try sending messages to a group chat channel.
** '''Verify''' that you can send messages
** '''Verify''' that you are receiving group chat messages.
* '''IM'''
** Try sending private IM messages to another avatar.
** '''Verify''' that the other avatar receives your messages
** '''Verify''' that you are able to receive their response.
* '''Display Names'''
** '''Verify''' that custom display names are visible for avatars that have them set.
** '''Verify''' that the display names of avatars are visible in your friends list.

=== Asset Download Tests ===
* Before starting this test, clear your viewer cache and relog.
* '''Texture'''
** '''Verify''' that textures load onto surfaces in your view.
* '''Sounds'''
** Locate the Button_click_down asset in your inventory. Double click the sound to play it.
** '''Verify''' that the sound plays.
* '''Notecard'''
** Locate the Community Standards notecard in the Library of your inventory.
** '''Verify''' that the notecard loads and is readable.
* '''Gestures'''
** Select a gesture from the "Gesture" menu at the bottom of the window.
** '''Verify''' that the gesture plays.
* '''Mesh'''
** Travel to a region with mesh assets available.
** '''Verify''' that the mesh assets rez and are visible.
* '''Legacy Fetch Methods'''
** Enable the Develop menu if you haven't already. (Me->Preferences->Advanced->Show Developer Menu)
** Disable HTTP Inventory and HTTP Textures in the Develop menu.
** Clear the viewer cache.
** Log back into Second Life.
** '''Verify''' that textures load onto surfaces in your view.
** '''Verify''' that your inventory loads.
** Re-enable HTTP Textures and HTTP inventory.
** Log out and back in for the next test.

=== Asset Creation Tests ===
* Move to a region where you have permission to build.
* '''Texture'''
** Upload a test image using the upload tool (Build->Upload->Image).
** When the upload is complete, apply that texture to an object.
** '''Verify''' that the image uploaded successfully.
* '''Sound'''
** Upload a test sound using the upload tool (Build->Upload->Sound)
** When the upload is complete, double click the sound in your inventory to play it back.
** '''Verify''' that the sound plays.
* '''Notecard'''
** In the inventory sidebar, click the "plus sign" (+) button at the bottom of the list of assets.
** In the menu that appears, select "New Notecard".
** Add some text in the body of the notecard and click save.
** Close the notecard
** Reopen the notecard from your inventory.
** '''Verify''' that the notecard text loads.
* '''Mesh'''
** Move to a mesh-enabled region.
** Select Build->Upload->Model to start the mesh upload process.
** In the file selection dialog, select the mesh object you prepared while setting up. The example file is named duck.dae.
** Select "Calculate weights & fee" at the bottom of the Upload Model dialog.
** After the upload fee has been calculated, select the "Upload" button.
** '''Verify''' that the mesh object is added to your inventory.
** Drag the mesh object out of your inventory onto the ground to rez it.
** '''Verify''' that the mesh object is rezzed.
* '''Object Creation'''
** Create a simple object using the build tools.
** '''Verify''' that the object is created
** '''Verify''' that you can take a copy of the created object into your inventory.
* '''Scripting'''
** Right click the object you created in the previous test and select edit.
** Select the content tab of the build floater.
** Click the New Script button.
** Double click the new script to edit.
** Edit the string "Hello, Avatar!" to be "Hi, Avatar!"
** Click save
** '''Verify''' that the script compiles.
** '''Verify''' that the object has sent the message "Hi, Avatar!".

=== Integrated Web Browser ===
* '''Browsing Test''' The integrated webkit browser should be able to browse while accessing the internet through a proxy.
** Enable the built-in browser. (Me->Preferences->Setup->"Use built-in browser", under "Web:").
** Enter a full url, like http://secondlife.com into text chat and send.
** Click the link in the text chat window.
** '''Verify''' that the built-in browser is able to access web content.

=== Media on a Prim ===
* '''Web Media'''
** '''Verify''' that web media is visible.
* '''Video Media'''
** '''Verify''' that video media is visible.

== Proxy Enabled, other HTTP through SOCKS 5 Proxy ==
* '''Repeat Connectivity Tests''' Verify that sending other HTTP traffic through the SOCKS 5 proxy works correctly.
** Configure the viewer as described in the '''Enable proxy connection with HTTP traffic sent through SOCKS 5 proxy.''' section above.
** '''Verify'' that you are able to successfully log into Second Life.
** Rerun the following list of test cases, which are described in the section above.
*** Viewer Initialization
*** Avatar Navigation and Movement
*** Avatar Communication
*** Asset Download Tests
*** Asset Upload Tests
*** Integrated Web Browser
*** Media On a Prim
** '''Verify''' that all tests pass.

== No Proxy Enabled ==
* '''Repeat Connectivity Tests''' Verify that users that are not using the proxy will not be negatively impacted by the change.
** Either test on another computer that is not firewalled, or relax the firewall restrictions on the testing network. If using the reference gateway configuration, run the ''nat_forward_all.sh'' script to allow traffic through without going through a proxy.
** Disable the proxy as described above.
** Rerun the following list of test cases, which are described in the section above.
*** Viewer Initialization
*** Avatar Navigation and Movement
*** Avatar Communication
*** Asset Download Tests
*** Asset Upload Tests
*** Integrated Web Browser
*** Media On a Prim
** '''Verify''' that all tests pass.
** '''Verify''' that overall viewer performance is approximately the same as usual for the machine you are testing on.
** Re-enable the firewall if you disabled it before further testing.

== SOCKS 5 with Username/Password Authentication ==
* '''Successful Login with SOCKS Authentication''' Test that the viewer can connect when the SOCKS 5 host requires a password.
** Enable both proxies, with "other" traffic going through SOCKS 5.
** Also in the proxy settings floater, select Username/Password as the SOCKS Authentication method.
** Enter your SOCKS 5 username and password in the appropriate fields. If you followed the reference gateway instructions, your linux username and password should work for the socks credentials.
** Select OK.
** Try to log in to Second Life.
** '''Verify''' that login is successful.
** Leave authentication enabled for the next test.
** Optional: The previous set of connectivity tests could be run in this mode as well to verify that the Username/Password authentication method works as well. This is a lower priority than the other three modes because this configuration is behaviorally very similar to the no authentication test, and should either connect or not connect.
* '''SOCKS 5 Password Security''' The SOCKS 5 password should not be stored in cleartext.
** Leave SOCKS 5 authentication enabled in the viewer from the previous test.
** Close all running instances of the viewer.
** Navigate to the user's Second Life settings directory.
** Search, using grep or ctrl-f in notepad depending on the platform, for the username and password you used to connect to the SOCKS 5 server in the previous step in the settings.xml that corresponds to the viewer version you are testing with (settings.xml if using a release version, settings_development.xml if using a development build, etc).
** '''Verify''' that the username and password do not appear in the settings files.
** Start the viewer and disable authentication.

----


= Pass/Fail Criteria =
* '''Passes''' if
** No unexpected behaviors are observed
* '''Fails''' if
** Deviation from expected behavior is observed
** A bug is detected that was not accounted for by this test plan
** Performance degradation is observed when the proxy is disabled.
* '''Known Issues'''
** SLVoice does not support proxies, therefore voice is not expected to work when running the viewer behind a strict firewall that blocks the ports used for voice communication. If voice is enabled, an error message will appear when the viewer fails to connect to the voice server.

= Tear Down =
* Disable all proxies in the viewer configuration.
* Disable the built-in browser.

User:Log Linden/Socks5Viewer/TestPlan/ProxyGateway

2011-08-19T21:30:41Z

Log Linden: Added wireshark info.

= Introduction =
These instructions will help you set up a simple Ubuntu gateway machine that will allow you to control access to the outside network for computers that are operating behind the gateway. This setup was created for testing the SOCKS 5 proxy. With some modification, the same setup could be used for testing various other network conditions, including throttling the connection speed down to something closer to residential DSL speeds. The instructions are intended for someone with a reasonable familiarity with Ubuntu Linux and will only discuss the customisations needed to set up the gateway.

= Requirements =
== Hardware ==
* A standard off-the-shelf PC with two Ethernet NICs
* 1 Ethernet switch for the "internal" network
* Network cables
* Other computers to actually test the viewer on.

== Software ==
* Ubuntu Linux 11.04 (Natty) [http://www.ubuntu.com/download/ubuntu/download install media] (Other flavors of Ubuntu, including Ubuntu server should work with these instructions as well.)

= Instructions =
== Connect network hardware ==
* Connect one network card to the outside network.
* Connect the other network card to the internal ethernet switch.
* Connect testing computers to the internal network switch.
[[File:Socks_test_setup.2.png|border|600px|SOCKS Testing Network Setup]]

== Install Ubuntu and Packages ==
* Install Ubuntu on the gateway machine. Consult the official Ubuntu install [https://help.ubuntu.com/community/GraphicalInstall instructions] for more information.
* Reboot into the installed system.
* Update the packages on the system.
<bash>
sudo apt-get update
sudo apt-get upgrade
</bash>
* Install some additional useful packages that we will need.
<bash> sudo apt-get install dnsmasq dante-server openssh </bash>
== Configure Network Interfaces ==
* IMPORTANT NOTE: For the purpose of this document, eth0 is the device that is connecting to the outside network, and eth1 is connecting to the internal network. Verify which is which on your setup.
<bash>ifconfig</bash>
Chances are, only one of the ethX devices will have been assigned an IP address by your network, this is the one connected to the external network. If this is not eth0 you need to either switch the network cables connected to the computer or remember to swap the interface names everywhere in the rest of this document. We are going to be assigning eth1 with a static IP address, which can cause problems if it conflicts with the rest of your network.
* Edit, with sudo, '/etc/network/interfaces' and replace its contents with the following
<bash>
auto lo eth0 eth1

iface lo inet loopback

# External network
iface eth0 inet dhcp

# Internal network
iface eth1 inet static
address 192.168.1.1
network 192.168.1.0
netmask 255.255.255.0
broadcast 192.168.1.255
</bash>
* This configuration makes eth0 continue to get its configuration through DHCP, and statically configures eth1. Listing both interfaces on the auto line will mean that they will automatically connect on startup.
* Because we are setting up the interfaces in this config file, we should probably prevent networkmanager from trying to do it as well.
<bash> sudo update-rc.d NetworkManager remove</bash>
* Restart the network
<bash>
sudo /etc/init.d/networking stop
sudo /etc/init.d/networking start
</bash>
* Verify the network configuration by looking for the correct IP addresses for eth0 and eth1.
<bash> ifconfig</bash>

== Set up DNS and DHCP ==
* dnsmasq is a lightweight combination DNS/DHCP server. For the anticipated number of clients for this network, it should be sufficient.
* Warning: Again, it is important to get the network interfaces correct for this. Running a rogue DHCP server on the wrong interface could cause major network problems. eth1 should be the '''internal''' network card.
* Replace /etc/dnsmasq.conf with the following:
<bash>
interface=eth1

dhcp-range=192.168.1.50,192.168.1.150,12h
dhcp-authoritative
dhcp-script=/bin/echo
</bash>
* Restart dnsmasq
<bash> sudo /etc/init.d/dnsmasq restart </bash>

== Set up the Firewall ==
* Save the following two scripts to ~/scripts
=== nat_forward_all.sh ===
<bash>
echo -e "\n\nLoading simple rc.firewall-iptables version $FWVER..\n"
DEPMOD=/sbin/depmod
MODPROBE=/sbin/modprobe

EXTIF="eth0"
INTIF="eth1"
echo " External Interface: $EXTIF"
echo " Internal Interface: $INTIF"

#======================================================================
#== No editing beyond this line is required for initial MASQ testing ==
echo -en " loading modules: "
echo " - Verifying that all kernel modules are ok"
$DEPMOD -a
echo "----------------------------------------------------------------------"
echo -en "ip_tables, "
$MODPROBE ip_tables
echo -en "nf_conntrack, "
$MODPROBE nf_conntrack
echo -en "nf_conntrack_ftp, "
$MODPROBE nf_conntrack_ftp
echo -en "nf_conntrack_irc, "
$MODPROBE nf_conntrack_irc
echo -en "iptable_nat, "
$MODPROBE iptable_nat
echo -en "nf_nat_ftp, "
$MODPROBE nf_nat_ftp
echo "----------------------------------------------------------------------"
echo -e " Done loading modules.\n"
echo " Enabling forwarding.."
echo "1" > /proc/sys/net/ipv4/ip_forward
echo " Enabling DynamicAddr.."
echo "1" > /proc/sys/net/ipv4/ip_dynaddr
echo " Clearing any existing rules and setting default policy.."https://wiki.secondlife.com/w/index.php?title=User:Log_Linden/Socks5Viewer/TestPlan/ProxyGateway

iptables-restore <<-EOF
*nat
-A POSTROUTING -o "$EXTIF" -j MASQUERADE
COMMIT
*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A FORWARD -i "$EXTIF" -o "$INTIF" -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -i "$INTIF" -o "$EXTIF" -j ACCEPT
-A FORWARD -j LOG
COMMIT
EOF

echo -e "\nrc.firewall-iptables v$FWVER done.\n"
</bash>
=== nat_block_all.sh ===
<bash>
echo -e "\n\nLoading simple rc.firewall-iptables version $FWVER..\n"
DEPMOD=/sbin/depmod
MODPROBE=/sbin/modprobe

EXTIF="eth0"
INTIF="eth1"
echo " External Interface: $EXTIF"
echo " Internal Interface: $INTIF"

#======================================================================
#== No editing beyond this line is required for initial MASQ testing ==
echo -en " loading modules: "
echo " - Verifying that all kernel modules are ok"
$DEPMOD -a
echo "----------------------------------------------------------------------"
echo -en "ip_tables, "
$MODPROBE ip_tables
echo -en "nf_conntrack, "
$MODPROBE nf_conntrack
echo -en "nf_conntrack_ftp, "
$MODPROBE nf_conntrack_ftp
echo -en "iptable_nat, "
$MODPROBE iptable_nat
echo -en "nf_nat_ftp, "
$MODPROBE nf_nat_ftp
echo "----------------------------------------------------------------------"
echo -e " Done loading modules.\n"
echo " Enabling forwarding.."
echo "1" > /proc/sys/net/ipv4/ip_forward
echo " Enabling DynamicAddr.."
echo "1" > /proc/sys/net/ipv4/ip_dynaddr
echo " Clearing any existing rules and setting default policy.."

iptables-restore <<-EOF
*nat
-A POSTROUTING -o "$EXTIF" -j MASQUERADE
COMMIT
*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A FORWARD -i "$INTIF" -j LOG
-A FORWARD -i "$INTIF" -j REJECT
COMMIT
EOF

echo -e "\nrc.firewall-iptables v$FWVER done.\n"
</bash>
* Make both scripts executable
<bash>
chmod a+x ~/scripts/nat_block_all.sh
chmod a+x ~/scripts/nat_forward_all.sh
</bash>
* Test the wide-open script. Inspect the output for errors indicating something is wrong.
<bash>
sudo ~/scripts/nat_forward_all.sh
</bash>
* If the previous command was successful and you got dns and dhcp configured before, you should be able to connect through your gateway on computers on the internal network.
* Test this now, by connecting a test computer to the network if you haven't already. Try browsing the web on one of the test machines as a quick test. Use '''ipconfig /all''' or '''ifconfig''' to see how the test computer is being configured. Expected values are below:
{| class="lltable" border="1"
|+ '''Test Machine Network Parameters'''

|--
!Parameter
!Expected Value

|--
| IP Address
| 192.168.1.50-192.168.1.150

|--
| Subnet Mask
| 255.255.255.0

|--
| Default Gateway
| 192.168.1.1

|--
| Nameserver (DNS Server)
| 192.168.1.1

|}

* If everything seems to be working correctly, make the wide-open config run during system startup.
<bash>
sudo cp nat_forward_all.sh /etc/init.d/nat.sh
sudo ln -s /etc/init.d/nat.sh /etc/rc2.d/S95masquradescript
</bash>

== Set up the SOCKS 5 proxy==
* Replace /etc/danted.conf with the following.
<pre>
logoutput: /var/log/dante.log

internal: eth1 port = 1080

external: eth0

method: username none
# Accept either username auth or no auth. If using username auth, use the same username and password that are used to sign on to this machine.

#user.privileged: proxy
user.notprivileged: nobody

### "client-rules" ###

client pass {
from: 192.168.1.0/24 port 1-65535 to: 0.0.0.0/0
}

client block {
from: 0.0.0.0/0 to: 0.0.0.0/0
log: connect error
}

### "socks-rules" ###
# Block connections to loopback interfaces
block {
from: 0.0.0.0/0 to: 127.0.0.0/8
log: connect error
}

# Allow udp reply packets from outside
pass {
from: 0.0.0.0/0 to: 192.168.1.0/24
command: udpreply
}

# Allow the internal network to connect to everything outside
pass {
from: 192.168.1.0/24 to: 0.0.0.0/0
protocol: tcp udp
}

# Block anything else
block {
from: 0.0.0.0/0 to: 0.0.0.0/0
log: connect error
}

</pre>
* Start the proxy server
<bash> sudo /etc/init.d/danted restart </bash>
* If you get a "Failed to open libc.so..." error message when starting the proxy server, this is caused by a [https://bugs.launchpad.net/ubuntu/+source/dante/+bug/767085 mistake] in the dante-server debian package. To work around this, create a simlink to the correct libc.so and try to start danted again.
<bash> sudo ln -sf /lib/i386-linux-gnu/libc-2.13.so /lib/i386-linux-gnu/libc.so </bash>
* Test connecting through the proxy by configuring the web browser on one of the test machines connected through the gateway to use the proxy.
* Restrict outgoing traffic through the gateway by enabling the more restrictive iptables configuration.
<bash> sudo ~/scripts/nat_block_all.sh </bash>
* In the proxy options section of the browser, supply 192.168.1.1 as the SOCKS server and 1080 as the port.
* Attempt to browse to an internet website. If you can browse as usual, the proxy is working correctly.
* Disable the proxy in the browser.

== Set up the HTTP (Web) proxy ==
=== Configure the HTTP proxy ===
* Edit /etc/squid/squid.conf. We will be editing the existing file instead of replacing it. We need to open up some ports, enable SSL communication via the CONNECT method, and disable caching.
* A patch that will give us the access we need:
<diff>
--- squid.conf.original 2011-07-11 13:58:12.640564821 -0400
+++ squid.conf 2011-08-16 15:22:55.420862811 -0400
@@ -606,8 +606,6 @@
# Example rule allowing access from your local networks.
# Adapt to list your (internal) IP networks from where browsing
# should be allowed
-acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
-acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
#
acl SSL_ports port 443 # https
@@ -628,6 +626,8 @@
acl Safe_ports port 901 # SWAT
acl purge method PURGE
acl CONNECT method CONNECT
+# Enable SSL via CONNECT
+acl SSL method CONNECT

# TAG: http_access
# Allowing or Denying access based on defined access lists
@@ -661,7 +661,8 @@
# Deny requests to unknown ports
http_access deny !Safe_ports
# Deny CONNECT to other than SSL ports
-http_access deny CONNECT !SSL_ports
+## Removed to allow connection to caps router on simhosts.
+#http_access deny CONNECT !SSL_ports
#
# We strongly recommend the following be uncommented to protect innocent
# web applications running on the proxy server who think the only
@@ -675,6 +676,8 @@
# from where browsing should be allowed
#http_access allow localnet
http_access allow localhost
+http_access allow localnet
+

# And finally deny all other access to this proxy
http_access deny all
@@ -1111,8 +1114,9 @@
# visible on the internal address.
#
# Squid normally listens to port 3128
-http_port 3128
+http_port 192.168.1.1:3128

+cache deny all
# TAG: https_port
# Note: This option is only available if Squid is rebuilt with the
# --enable-ssl option
@@ -3939,7 +3943,7 @@
# "0". May be overridden with -u on the command line.
#
#Default:
-# icp_port 3130
+icp_port 0

# TAG: htcp_port
# The port number where Squid sends and receives HTCP queries to

</diff>

* To apply the patch, save it to a file named squid.diff in your home directory and run the following command:
<bash>
sudo patch /etc/squid/squid.conf ~/squid.diff
</bash>

* If you would rather edit by hand, a sequence of instructions to do the above are listed below.1
* Look for the following line:
http_port 3128
* Replace with the following:
http_port 192.168.1.1:3128
cache deny all
* Look for the following lines:
acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network

* Replace with
acl localnet src 192.168.1.0/8 # RFC1918 possible internal network

* Look for the following line:
acl CONNECT method CONNECT
* Append two lines after to make it look like this:
acl CONNECT method CONNECT
# Enable SSL via CONNECT
acl SSL method CONNECT

* Comment out the following line:
http_access deny CONNECT !SSL_ports
* It should look like this:
#http_access deny CONNECT !SSL_ports

* Look for the following line:
http_access allow localhost
* Append another line after it so that it now looks like this:
http_access allow localhost
http_access allow localnet

* Now that the configuration file is correct, we need to restart the squid proxy:
<bash>
sudo stop squid
sudo start squid
</bash>
* Examine syslog for any errors related to squid.
<bash>
sudo tail /var/log/syslog
</bash>

=== Test the HTTP Proxy ===
* Restrict outgoing traffic through the gateway by enabling the more restrictive iptables configuration.
<bash> sudo ~/scripts/nat_block_all.sh </bash>
* In the proxy options section of the browser on the test machine, supply 192.168.1.1 as the HTTP and HTTPS proxy server with 3128 as the port in both cases.
* Remove any SOCKS proxy configuration in the browser.
* Attempt to browse to an internet website. Also try browsing to an https:// website such as [https://codereview.secondlife.com https://codereview.secondlife.com]. If you can browse as usual, the proxy is working correctly.
* Disable the proxy in the browser.

== Cleanup ==
* Reboot the machine, using the graphical menus to reboot or the following command. Verify that everything still works as before.
<bash> sudo shutdown -r now </bash>
* Note that we left the unrestricted firewall configuration as the default. When the gateway is rebooted, you will need to rerun '''~/scripts/nat_blocked_all.sh''' to restrict connections again. If you would like that to be the default state, copy '''~/scripts/nat_blocked_all.sh''' to '''/etc/init.d/nat.sh'''.

== Packet Capture Tools ==
* On a machine with the X11 graphical environment, you can use wireshark to capture packets going through the computer. Install wireshark with the following command.
<bash> sudo apt-get install wireshar <bash>
* Allow non-root users to perform captures. Note that this should not be done on a machine that you do not trust all the users to monitor traffic.
<bash> sudo setcap 'CAP_NET_RAW+eip CAP_NET_ADMIN+eip' /usr/bin/dumpcap </bash>
* Start wireshark. In the list of capture device, select "pseudo-device that captures on all interface". The program should be capturing packets.
* Use the filter box at the top to filter for specific protocols, like "http" or certain hosts with strings like "ip.addr == 192.168.1.120".
= Useful References =
If you run into difficulties with these instructions, there is more information in the official documentation. I based the configurations in this document mostly from the following sites:
*[https://help.ubuntu.com/community/Router Ubuntu Router Instructions]

User:Log Linden/Socks5Viewer/TestPlan

2011-08-19T20:06:28Z

Log Linden: /* Configuration Consistency Checks */

[[Category:Test Scripts]]
{| cellspacing="0" cellpadding="0" style="clear: {{{clear|right}}}; margin-bottom: .5em; float: right; padding: .5em 0 .8em 1.4em; background: none; width: {{{width|{{{1|auto}}}}}};" {{*if:{{{limit|}}}|class="toclimit-{{{limit}}}"}}
| __TOC__
|}
= Scope =
* This test is to verify that newly added proxy support in the viewer works as expected.
* The user story that prompted the changes is [https://jira.secondlife.com/browse/STORM-1112 STORM-1112 ].
* This test will only be meaningful if performed in a network environment that does not have access to second life.
* The test also requires a working web proxy host and SOCKS 5 proxy host.
* Estimated running time: 3 hours/platform after securing the appropriate test environment.

= Set-up =
== Environment ==
* Viewer: This test requires a build of the viewer that contains the LLProxy code. Grab the latest for your platform from the link below:
{{ViewerInstallers|{{JiraIssue|STORM-1112|Implement SOCKS 5 proxy}}| Allow the Second Life Viewer to connect through a SOCKS 5 proxy. |task=log_viewer-socks5|repo=https://bitbucket.org/log_linden/viewer_socks5}}
* Server: The test requires testing of mesh upload and download functionality, so access to a region with mesh support is required. Agni or Aditi are each fine. Region crossing will also be tested, so adjacent regions to test in will also be required.
* A restrictive, firewalled network to connect the testing machine to is required to obtain valid test results.
* A working web proxy host and a working SOCKS 5 host are required to complete the test.
* Instructions to set up a reference Ubuntu Linux server that will act as a firewall and proxy gateway [[User:Log_Linden/Socks5Viewer/TestPlan/ProxyGateway | are available]].
* While 3rd party testers are welcome to set up a duplicate of our reference gateway server, we are also interested in results you might get in your organization's specific network setup, rather than using our reference setup. Since you might not be allowed to reconfigure your organization's firewall or proxy host, feel free to only test in the proxy configuration your organization supports and report on results you observe.

== Other ==
* Second Life account that is able to upload mesh assets on the grid being tested.
* Your avatar should be a member of a group and be allowed to send messages in that group for testing.
* Part of the test is making sure land parcel media is functional. Find somewhere in world that has botha
* Sandbox, or other area where building is allowed.
* Enable advanced mode. The proxy options are not available in basic mode.
* Have a test image file, sound file, and collada model available to test upload functionality. A sample collada model is available from the [collada.org website | https://collada.org/owl/download.php?sess=0&parent=126&expand=1&order=name&curview=0&binary=1&id=698/ ].
* To test the gpu_table and feature_table download functionality of the viewer, a packet capture tool on the proxy host such as wireshark or tcp_dup is necessary to verify that the request tool is making use of the proxy. This might not be possible if you do not have access to your organization's proxy host.

= Common Procedures =
Refer to this section when asked to do one of the following in a test step.
* '''Enable proxy connection with HTTP traffic sent through web proxy.'''
** Change these settings before logging into Second Life.
** Open the Proxy settings floater. Me->Preferences->Setup->"Adjust Proxy Settings"
** Check "Use HTTP Proxy for Web pages" and enter the address and port number.
** Check "Use SOCKS 5 Proxy for UDP traffic" and enter the address and port number.
** Under other HTTP traffic proxy, select "Use HTTP Proxy".
** Click OK.

* '''Enable proxy connection with HTTP traffic sent through SOCKS 5 proxy.'''
** Change these settings before logging into Second Life.
** Open the Proxy settings floater. Me->Preferences->Setup->"Adjust Proxy Settings"
** Check "Use HTTP Proxy for Web pages" and enter the address and port number.
** Check "Use SOCKS 5 Proxy for UDP traffic" and enter the address and port number.
** Under other HTTP traffic proxy, select "Use SOCKS 5 Proxy".
** Click OK.

* '''Disable all proxies'''
** Change these settings before logging into Second Life.
** Open the Proxy settings floater. Me->Preferences->Setup->"Adjust Proxy Settings"
** Uncheck "Use HTTP Proxy for Web pages".
** Uncheck "Use SOCKS 5 Proxy for UDP traffic".
** Click OK.

* '''Clear Viewer Caches'''
** Click the "Clear Cache" button on the advanced tab of the preferences floater.
** Confirm that you want to clear the cache.
** Restart the Viewer.

= Test Steps =
== Configuration Consistency Checks ==
* '''Expected Defaults''' Check the default configuration.
** Install a version of the viewer that supports LLProxy communication.
** Start the viewer that was installed, but do not log in.
** Navigate to the proxy control floater (Me->Preferences->Setup->Adjust proxy Settings.
** Inspect the settings.
** '''Verify''' that both proxies are disabled.
** Leave this floater open for the next test.
* '''Invalid HTTP Proxy Configuration Error-Handling''' Test HTTP via socks when socks is disabled.
** Enable both proxies, enter valid information for both proxies.
** Change the "Other HTTP traffic proxy" option to "Use SOCKS 5 proxy".
** Quit the viewer.
** Edit the settings.xml file that corresponds to the channel of the viewer you are using to test with (e.g. settings_developer.xml, settings.xml, settings_beta.xml, etc.).
** Change the value of Socks5ProxyEnabled to "0". The block should look like the following:
<xml>
<key>Socks5ProxyEnabled</key>
<map>
<key>Comment</key>
<string>Use Socks5 Proxy</string>
<key>Persist</key>
<integer>1</integer>
<key>Type</key>
<string>Boolean</string>
<key>Value</key>
<integer>0</integer>
</map>
</xml>
** Restart the viewer.
** '''Verify''' that the viewer doesn't crash
** Open the proxy preferences floater.
** '''Verify''' that the "Other HTTP traffic" proxy option is now set to "Do not proxy".
** Quit the viewer.
** '''Verify''' that Secondlife.log contains the following warning:
"Invalid other HTTP proxy configuration."
* '''Invalid Authentication Configuration Error-Handling.''' Test that an unexpected authentication method will not crash the viewer.
** Before starting the viewer, replace the block controlling the Socks5AuthType in settings.xml with another with a fake value. The following block should work.
<xml>
<key>Socks5AuthType</key>
<map>
<key>Comment</key>
<string>Selected Auth mechanism for Socks5</string>
<key>Persist</key>
<integer>1</integer>
<key>Type</key>
<string>String</string>
<key>Value</key>
<string>FakeAuth</string>
</map>
</xml>
** Start the viewer, but do not log in.
** '''Verify''' that the viewer doesn't crash.
** '''Verify''' that in the settings proxy floater, that authentication is disabled.
** Close the viewer.
** '''Verify''' that Secondlife.log contains the following warning:
"Invalid SOCKS 5 authentication type."

== Proxy Enabled, other HTTP through Web Proxy ==
* Follow the instructions above to enable the proxy and send HTTP traffic through the web proxy.
* This should be run with the firewall fully enabled to ensure the only traffic is being sent through the proxy.
* '''Verify''' that you are able to successfully log into Second Life.

=== Viewer Initialization ===
* '''HTTP Tables Loading''' Verify that the viewer is able to fetch the GPU table and feature table via the proxy.
** The proxy should be enabled before starting this test.
** Close the viewer.
** Start a packet capture on the proxy host that captures on all interfaces. Note: Even if you are unable to use packet filtering software, complete the test and verify that the error strings below are not in the log file.
** Start the viewer but do not log in.
** Inspect the capture for an HTTP request for an HTTP GET for a file of the form gpu_table.X.Y.Z.txt and for featuretable.X.Y.Z.txt.
** '''Verify''' that there was a request originating from the test machine for each of these files, and a subsequent request from the proxy host for the same files. It is normal for each of these requests to receive a 404 response.
** Close the viewer.
** Inspect the Secondlife.log file.
** '''Verify''' that there are no logs matching the following in Secondlife.log.
2011-08-18T21:42:07Z WARNING: LLURLRequest::process_impl: URLRequest Error: 56, Failure when receiving data from the peer, http://viewer-settings.secondlife.com/featuretable_xp.3.0.1.238013.txt
2011-08-18T21:42:07Z INFO: LLPumpIO::processChain: Pump generated pipe err: 'STATUS_ERROR'
2011-08-18T21:42:07Z WARNING: LLURLRequest::process_impl: URLRequest Error: 56, Failure when receiving data from the peer, http://viewer-settings.secondlife.com/gpu_table.3.0.1.238013.txt
2011-08-18T21:42:07Z INFO: LLPumpIO::processChain: Pump generated pipe err: 'STATUS_ERROR'
* '''Login Screen Renders Correctly''' The logon screen should be able to load content from the web using the configured proxy.
** Start the viewer, but do not log in.
**'''Verify''' that the contents of the login screen are displayed.

=== Avatar Navigation and Movement ===
* '''Walking'''
** '''Verify''' that your avatar can move around the world.
* '''Sitting'''
** '''Verify''' that your avatar can sit on objects.
* '''Flying'''
** '''Verify''' that you can fly around the region.
* '''World Map'''
** Open the World Map Floater (World->World Map).
** '''Verify''' that map tiles load and display the layout of the surrounding regions.
** '''Verify''' that green dots representing avatars are displayed.
** Close the World Map.
* '''Minimap'''
** Open the Mini-Map Floater (World->Mini-Map).
** '''Verify''' that map tiles are displayed.
* '''Region Crossing'''
** Fly or walk across a region boundary.
** '''Verify''' that you successfully arrive in the other region.
* '''Intra-region teleport'''
** Teleport by double clicking in the World Map floater, within the current region.
** '''Verify''' that you arrive in the place you clicked.
* '''Inter-region teleport'''
** Teleport by double clicking in the World Map floater, somewhere other than the current region.
** '''Verify''' that you arrive in the new region.

=== Avatar Communication ===
* '''Local Chat'''
** Try sending messages to others avatars standing nearby.
** '''Verify''' that the other people receive your messages
** '''Verify''' that you can receive messages from other people.
* '''Group Chat'''
** Try sending messages to a group chat channel.
** '''Verify''' that you can send messages
** '''Verify''' that you are receiving group chat messages.
* '''IM'''
** Try sending private IM messages to another avatar.
** '''Verify''' that the other avatar receives your messages
** '''Verify''' that you are able to receive their response.
* '''Display Names'''
** '''Verify''' that custom display names are visible for avatars that have them set.
** '''Verify''' that the display names of avatars are visible in your friends list.

=== Asset Download Tests ===
* Before starting this test, clear your viewer cache and relog.
* '''Texture'''
** '''Verify''' that textures load onto surfaces in your view.
* '''Sounds'''
** Locate the Button_click_down asset in your inventory. Double click the sound to play it.
** '''Verify''' that the sound plays.
* '''Notecard'''
** Locate the Community Standards notecard in the Library of your inventory.
** '''Verify''' that the notecard loads and is readable.
* '''Gestures'''
** Select a gesture from the "Gesture" menu at the bottom of the window.
** '''Verify''' that the gesture plays.
* '''Mesh'''
** Travel to a region with mesh assets available.
** '''Verify''' that the mesh assets rez and are visible.
* '''Legacy Fetch Methods'''
** Enable the Develop menu if you haven't already. (Me->Preferences->Advanced->Show Developer Menu)
** Disable HTTP Inventory and HTTP Textures in the Develop menu.
** Clear the viewer cache.
** Log back into Second Life.
** '''Verify''' that textures load onto surfaces in your view.
** '''Verify''' that your inventory loads.

=== Asset Creation Tests ===
* Move to a region where you have permission to build.
* '''Texture'''
** Upload a test image using the upload tool (Build->Upload->Image).
** When the upload is complete, apply that texture to an object.
** '''Verify''' that the image uploaded successfully.
* '''Sound'''
** Upload a test sound using the upload tool (Build->Upload->Sound)
** When the upload is complete, double click the sound in your inventory to play it back.
** '''Verify''' that the sound plays.
* '''Notecard'''
** In the inventory sidebar, click the "plus sign" (+) button at the bottom of the list of assets.
** In the menu that appears, select "New Notecard".
** Add some text in the body of the notecard and click save.
** Close the notecard
** Reopen the notecard from your inventory.
** '''Verify''' that the notecard text loads.
* '''Mesh'''
** Move to a mesh-enabled region.
** Select Build->Upload->Model to start the mesh upload process.
** In the file selection dialog, select the mesh object you prepared while setting up. The example file is named duck.dae.
** Select "Calculate weights & fee" at the bottom of the Upload Model dialog.
** After the upload fee has been calculated, select the "Upload" button.
** '''Verify''' that the mesh object is added to your inventory.
** Drag the mesh object out of your inventory onto the ground to rez it.
** '''Verify''' that the mesh object is rezzed.
* '''Object Creation'''
** Create a simple object using the build tools.
** '''Verify''' that the object is created
** '''Verify''' that you can take a copy of the created object into your inventory.
* '''Scripting'''
** Right click the object you created in the previous test and select edit.
** Select the content tab of the build floater.
** Click the New Script button.
** Double click the new script to edit.
** Edit the string "Hello, Avatar!" to be "Hi, Avatar!"
** Click save
** '''Verify''' that the script compiles.
** '''Verify''' that the object has sent the message "Hi, Avatar!".

=== Integrated Web Browser ===
* '''Browsing Test''' The integrated webkit browser should be able to browse while accessing the internet through a proxy.
** Enable the built-in browser. (Me->Preferences->Setup->"Use built-in browser", under "Web:").
** Enter a full url, like http://secondlife.com into text chat and send.
** Click the link in the text chat window.
** '''Verify''' that the built-in browser is able to access web content.

=== Media on a Prim ===
* '''Web Media'''
** '''Verify''' that web media is visible.
* '''Video Media'''
** '''Verify''' that video media is visible.

== Proxy Enabled, other HTTP through SOCKS 5 Proxy ==
* '''Repeat Connectivity Tests''' Verify that sending other HTTP traffic through the SOCKS 5 proxy works correctly.
** Configure the viewer as described in the '''Enable proxy connection with HTTP traffic sent through SOCKS 5 proxy.''' section above.
** '''Verify'' that you are able to successfully log into Second Life.
** Rerun the following list of test cases, which are described in the section above.
*** Viewer Initialization
*** Avatar Navigation and Movement
*** Avatar Communication
*** Asset Download Tests
*** Asset Upload Tests
*** Integrated Web Browser
*** Media On a Prim
** '''Verify''' that all tests pass.

== No Proxy Enabled ==
* '''Repeat Connectivity Tests''' Verify that users that are not using the proxy will not be negatively impacted by the change.
** Either test on another computer that is not firewalled, or relax the firewall restrictions on the testing network. If using the reference gateway configuration, run the ''nat_forward_all.sh'' script to allow traffic through without going through a proxy.
** Disable the proxy as described above.
** Rerun the following list of test cases, which are described in the section above.
*** Viewer Initialization
*** Avatar Navigation and Movement
*** Avatar Communication
*** Asset Download Tests
*** Asset Upload Tests
*** Integrated Web Browser
*** Media On a Prim
** '''Verify''' that all tests pass.
** '''Verify''' that overall viewer performance is approximately the same as usual for the machine you are testing on.
** Re-enable the firewall if you disabled it before further testing.

== SOCKS 5 with Username/Password Authentication ==
* '''Successful Login with SOCKS Authentication''' Test that the viewer can connect when the SOCKS 5 host requires a password.
** Enable both proxies, with "other" traffic going through SOCKS 5.
** Also in the proxy settings floater, select Username/Password as the SOCKS Authentication method.
** Enter your SOCKS 5 username and password in the appropriate fields. If you followed the reference gateway instructions, your linux username and password should work for the socks credentials.
** Select OK.
** Try to log in to Second Life.
** '''Verify''' that login is successful.
** Leave authentication enabled for the next test.
** Optional: The previous set of connectivity tests could be run in this mode as well to verify that the Username/Password authentication method works as well. This is a lower priority than the other three modes because this configuration is behaviorally very similar to the no authentication test, and should either connect or not connect.
* '''SOCKS 5 Password Security''' The SOCKS 5 password should not be stored in cleartext.
** Leave SOCKS 5 authentication enabled in the viewer from the previous test.
** Close all running instances of the viewer.
** Navigate to the user's Second Life settings directory.
** Search, using grep or ctrl-f in notepad depending on the platform, for the username and password you used to connect to the SOCKS 5 server in the previous step in the settings.xml that corresponds to the viewer version you are testing with (settings.xml if using a release version, settings_development.xml if using a development build, etc).
** '''Verify''' that the username and password do not appear in the settings files.
** Start the viewer and disable authentication.

----


= Pass/Fail Criteria =
* '''Passes''' if
** No unexpected behaviors are observed
* '''Fails''' if
** Deviation from expected behavior is observed
** A bug is detected that was not accounted for by this test plan
** Performance degradation is observed when the proxy is disabled.
* '''Known Issues'''
** SLVoice does not support proxies, therefore voice is not expected to work when running the viewer behind a strict firewall that blocks the ports used for voice communication. If voice is enabled, an error message will appear when the viewer fails to connect to the voice server.

= Tear Down =
* Disable all proxies in the viewer configuration.
* Disable the built-in browser.

User:Log Linden/Socks5Viewer/TestPlan

2011-08-19T20:06:05Z

Log Linden: /* Configuration Consistency Checks */

[[Category:Test Scripts]]
{| cellspacing="0" cellpadding="0" style="clear: {{{clear|right}}}; margin-bottom: .5em; float: right; padding: .5em 0 .8em 1.4em; background: none; width: {{{width|{{{1|auto}}}}}};" {{*if:{{{limit|}}}|class="toclimit-{{{limit}}}"}}
| __TOC__
|}
= Scope =
* This test is to verify that newly added proxy support in the viewer works as expected.
* The user story that prompted the changes is [https://jira.secondlife.com/browse/STORM-1112 STORM-1112 ].
* This test will only be meaningful if performed in a network environment that does not have access to second life.
* The test also requires a working web proxy host and SOCKS 5 proxy host.
* Estimated running time: 3 hours/platform after securing the appropriate test environment.

= Set-up =
== Environment ==
* Viewer: This test requires a build of the viewer that contains the LLProxy code. Grab the latest for your platform from the link below:
{{ViewerInstallers|{{JiraIssue|STORM-1112|Implement SOCKS 5 proxy}}| Allow the Second Life Viewer to connect through a SOCKS 5 proxy. |task=log_viewer-socks5|repo=https://bitbucket.org/log_linden/viewer_socks5}}
* Server: The test requires testing of mesh upload and download functionality, so access to a region with mesh support is required. Agni or Aditi are each fine. Region crossing will also be tested, so adjacent regions to test in will also be required.
* A restrictive, firewalled network to connect the testing machine to is required to obtain valid test results.
* A working web proxy host and a working SOCKS 5 host are required to complete the test.
* Instructions to set up a reference Ubuntu Linux server that will act as a firewall and proxy gateway [[User:Log_Linden/Socks5Viewer/TestPlan/ProxyGateway | are available]].
* While 3rd party testers are welcome to set up a duplicate of our reference gateway server, we are also interested in results you might get in your organization's specific network setup, rather than using our reference setup. Since you might not be allowed to reconfigure your organization's firewall or proxy host, feel free to only test in the proxy configuration your organization supports and report on results you observe.

== Other ==
* Second Life account that is able to upload mesh assets on the grid being tested.
* Your avatar should be a member of a group and be allowed to send messages in that group for testing.
* Part of the test is making sure land parcel media is functional. Find somewhere in world that has botha
* Sandbox, or other area where building is allowed.
* Enable advanced mode. The proxy options are not available in basic mode.
* Have a test image file, sound file, and collada model available to test upload functionality. A sample collada model is available from the [collada.org website | https://collada.org/owl/download.php?sess=0&parent=126&expand=1&order=name&curview=0&binary=1&id=698/ ].
* To test the gpu_table and feature_table download functionality of the viewer, a packet capture tool on the proxy host such as wireshark or tcp_dup is necessary to verify that the request tool is making use of the proxy. This might not be possible if you do not have access to your organization's proxy host.

= Common Procedures =
Refer to this section when asked to do one of the following in a test step.
* '''Enable proxy connection with HTTP traffic sent through web proxy.'''
** Change these settings before logging into Second Life.
** Open the Proxy settings floater. Me->Preferences->Setup->"Adjust Proxy Settings"
** Check "Use HTTP Proxy for Web pages" and enter the address and port number.
** Check "Use SOCKS 5 Proxy for UDP traffic" and enter the address and port number.
** Under other HTTP traffic proxy, select "Use HTTP Proxy".
** Click OK.

* '''Enable proxy connection with HTTP traffic sent through SOCKS 5 proxy.'''
** Change these settings before logging into Second Life.
** Open the Proxy settings floater. Me->Preferences->Setup->"Adjust Proxy Settings"
** Check "Use HTTP Proxy for Web pages" and enter the address and port number.
** Check "Use SOCKS 5 Proxy for UDP traffic" and enter the address and port number.
** Under other HTTP traffic proxy, select "Use SOCKS 5 Proxy".
** Click OK.

* '''Disable all proxies'''
** Change these settings before logging into Second Life.
** Open the Proxy settings floater. Me->Preferences->Setup->"Adjust Proxy Settings"
** Uncheck "Use HTTP Proxy for Web pages".
** Uncheck "Use SOCKS 5 Proxy for UDP traffic".
** Click OK.

* '''Clear Viewer Caches'''
** Click the "Clear Cache" button on the advanced tab of the preferences floater.
** Confirm that you want to clear the cache.
** Restart the Viewer.

= Test Steps =
== Configuration Consistency Checks ==
* '''Expected Defaults''' Check the default configuration.
** Install a version of the viewer that supports LLProxy communication.
** Start the viewer that was installed, but do not log in.
** Navigate to the proxy control floater (Me->Preferences->Setup->Adjust proxy Settings.
** Inspect the settings.
** '''Verify''' that both proxies are disabled.
** Leave this floater open for the next test.
* '''Invalid HTTP Proxy Configuration Error-Handling''' Test HTTP via socks when socks is disabled.
** Enable both proxies, enter valid information for both proxies.
** Change the "Other HTTP traffic proxy" option to "Use SOCKS 5 proxy".
** Quit the viewer.
** Edit the settings.xml file that corresponds to the channel of the viewer you are using to test with (e.g. settings_developer.xml, settings.xml, settings_beta.xml, etc.).
** Change the value of Socks5ProxyEnabled to "0". The block should look like the following:
<xml>
<key>Socks5ProxyEnabled</key>
<map>
<key>Comment</key>
<string>Use Socks5 Proxy</string>
<key>Persist</key>
<integer>1</integer>
<key>Type</key>
<string>Boolean</string>
<key>Value</key>
<integer>0</integer>
</map>
</xml>
** Restart the viewer.
** '''Verify''' that the viewer doesn't crash
** Open the proxy preferences floater.
** '''Verify''' that the "Other HTTP traffic" proxy option is now set to '''Do not proxy'''.
** Quit the viewer.
** '''Verify''' that Secondlife.log contains the following warning:
"Invalid other HTTP proxy configuration."
* '''Invalid Authentication Configuration Error-Handling.''' Test that an unexpected authentication method will not crash the viewer.
** Before starting the viewer, replace the block controlling the Socks5AuthType in settings.xml with another with a fake value. The following block should work.
<xml>
<key>Socks5AuthType</key>
<map>
<key>Comment</key>
<string>Selected Auth mechanism for Socks5</string>
<key>Persist</key>
<integer>1</integer>
<key>Type</key>
<string>String</string>
<key>Value</key>
<string>FakeAuth</string>
</map>
</xml>
** Start the viewer, but do not log in.
** '''Verify''' that the viewer doesn't crash.
** '''Verify''' that in the settings proxy floater, that authentication is disabled.
** Close the viewer.
** '''Verify''' that Secondlife.log contains the following warning:
"Invalid SOCKS 5 authentication type."

== Proxy Enabled, other HTTP through Web Proxy ==
* Follow the instructions above to enable the proxy and send HTTP traffic through the web proxy.
* This should be run with the firewall fully enabled to ensure the only traffic is being sent through the proxy.
* '''Verify''' that you are able to successfully log into Second Life.

=== Viewer Initialization ===
* '''HTTP Tables Loading''' Verify that the viewer is able to fetch the GPU table and feature table via the proxy.
** The proxy should be enabled before starting this test.
** Close the viewer.
** Start a packet capture on the proxy host that captures on all interfaces. Note: Even if you are unable to use packet filtering software, complete the test and verify that the error strings below are not in the log file.
** Start the viewer but do not log in.
** Inspect the capture for an HTTP request for an HTTP GET for a file of the form gpu_table.X.Y.Z.txt and for featuretable.X.Y.Z.txt.
** '''Verify''' that there was a request originating from the test machine for each of these files, and a subsequent request from the proxy host for the same files. It is normal for each of these requests to receive a 404 response.
** Close the viewer.
** Inspect the Secondlife.log file.
** '''Verify''' that there are no logs matching the following in Secondlife.log.
2011-08-18T21:42:07Z WARNING: LLURLRequest::process_impl: URLRequest Error: 56, Failure when receiving data from the peer, http://viewer-settings.secondlife.com/featuretable_xp.3.0.1.238013.txt
2011-08-18T21:42:07Z INFO: LLPumpIO::processChain: Pump generated pipe err: 'STATUS_ERROR'
2011-08-18T21:42:07Z WARNING: LLURLRequest::process_impl: URLRequest Error: 56, Failure when receiving data from the peer, http://viewer-settings.secondlife.com/gpu_table.3.0.1.238013.txt
2011-08-18T21:42:07Z INFO: LLPumpIO::processChain: Pump generated pipe err: 'STATUS_ERROR'
* '''Login Screen Renders Correctly''' The logon screen should be able to load content from the web using the configured proxy.
** Start the viewer, but do not log in.
**'''Verify''' that the contents of the login screen are displayed.

=== Avatar Navigation and Movement ===
* '''Walking'''
** '''Verify''' that your avatar can move around the world.
* '''Sitting'''
** '''Verify''' that your avatar can sit on objects.
* '''Flying'''
** '''Verify''' that you can fly around the region.
* '''World Map'''
** Open the World Map Floater (World->World Map).
** '''Verify''' that map tiles load and display the layout of the surrounding regions.
** '''Verify''' that green dots representing avatars are displayed.
** Close the World Map.
* '''Minimap'''
** Open the Mini-Map Floater (World->Mini-Map).
** '''Verify''' that map tiles are displayed.
* '''Region Crossing'''
** Fly or walk across a region boundary.
** '''Verify''' that you successfully arrive in the other region.
* '''Intra-region teleport'''
** Teleport by double clicking in the World Map floater, within the current region.
** '''Verify''' that you arrive in the place you clicked.
* '''Inter-region teleport'''
** Teleport by double clicking in the World Map floater, somewhere other than the current region.
** '''Verify''' that you arrive in the new region.

=== Avatar Communication ===
* '''Local Chat'''
** Try sending messages to others avatars standing nearby.
** '''Verify''' that the other people receive your messages
** '''Verify''' that you can receive messages from other people.
* '''Group Chat'''
** Try sending messages to a group chat channel.
** '''Verify''' that you can send messages
** '''Verify''' that you are receiving group chat messages.
* '''IM'''
** Try sending private IM messages to another avatar.
** '''Verify''' that the other avatar receives your messages
** '''Verify''' that you are able to receive their response.
* '''Display Names'''
** '''Verify''' that custom display names are visible for avatars that have them set.
** '''Verify''' that the display names of avatars are visible in your friends list.

=== Asset Download Tests ===
* Before starting this test, clear your viewer cache and relog.
* '''Texture'''
** '''Verify''' that textures load onto surfaces in your view.
* '''Sounds'''
** Locate the Button_click_down asset in your inventory. Double click the sound to play it.
** '''Verify''' that the sound plays.
* '''Notecard'''
** Locate the Community Standards notecard in the Library of your inventory.
** '''Verify''' that the notecard loads and is readable.
* '''Gestures'''
** Select a gesture from the "Gesture" menu at the bottom of the window.
** '''Verify''' that the gesture plays.
* '''Mesh'''
** Travel to a region with mesh assets available.
** '''Verify''' that the mesh assets rez and are visible.
* '''Legacy Fetch Methods'''
** Enable the Develop menu if you haven't already. (Me->Preferences->Advanced->Show Developer Menu)
** Disable HTTP Inventory and HTTP Textures in the Develop menu.
** Clear the viewer cache.
** Log back into Second Life.
** '''Verify''' that textures load onto surfaces in your view.
** '''Verify''' that your inventory loads.

=== Asset Creation Tests ===
* Move to a region where you have permission to build.
* '''Texture'''
** Upload a test image using the upload tool (Build->Upload->Image).
** When the upload is complete, apply that texture to an object.
** '''Verify''' that the image uploaded successfully.
* '''Sound'''
** Upload a test sound using the upload tool (Build->Upload->Sound)
** When the upload is complete, double click the sound in your inventory to play it back.
** '''Verify''' that the sound plays.
* '''Notecard'''
** In the inventory sidebar, click the "plus sign" (+) button at the bottom of the list of assets.
** In the menu that appears, select "New Notecard".
** Add some text in the body of the notecard and click save.
** Close the notecard
** Reopen the notecard from your inventory.
** '''Verify''' that the notecard text loads.
* '''Mesh'''
** Move to a mesh-enabled region.
** Select Build->Upload->Model to start the mesh upload process.
** In the file selection dialog, select the mesh object you prepared while setting up. The example file is named duck.dae.
** Select "Calculate weights & fee" at the bottom of the Upload Model dialog.
** After the upload fee has been calculated, select the "Upload" button.
** '''Verify''' that the mesh object is added to your inventory.
** Drag the mesh object out of your inventory onto the ground to rez it.
** '''Verify''' that the mesh object is rezzed.
* '''Object Creation'''
** Create a simple object using the build tools.
** '''Verify''' that the object is created
** '''Verify''' that you can take a copy of the created object into your inventory.
* '''Scripting'''
** Right click the object you created in the previous test and select edit.
** Select the content tab of the build floater.
** Click the New Script button.
** Double click the new script to edit.
** Edit the string "Hello, Avatar!" to be "Hi, Avatar!"
** Click save
** '''Verify''' that the script compiles.
** '''Verify''' that the object has sent the message "Hi, Avatar!".

=== Integrated Web Browser ===
* '''Browsing Test''' The integrated webkit browser should be able to browse while accessing the internet through a proxy.
** Enable the built-in browser. (Me->Preferences->Setup->"Use built-in browser", under "Web:").
** Enter a full url, like http://secondlife.com into text chat and send.
** Click the link in the text chat window.
** '''Verify''' that the built-in browser is able to access web content.

=== Media on a Prim ===
* '''Web Media'''
** '''Verify''' that web media is visible.
* '''Video Media'''
** '''Verify''' that video media is visible.

== Proxy Enabled, other HTTP through SOCKS 5 Proxy ==
* '''Repeat Connectivity Tests''' Verify that sending other HTTP traffic through the SOCKS 5 proxy works correctly.
** Configure the viewer as described in the '''Enable proxy connection with HTTP traffic sent through SOCKS 5 proxy.''' section above.
** '''Verify'' that you are able to successfully log into Second Life.
** Rerun the following list of test cases, which are described in the section above.
*** Viewer Initialization
*** Avatar Navigation and Movement
*** Avatar Communication
*** Asset Download Tests
*** Asset Upload Tests
*** Integrated Web Browser
*** Media On a Prim
** '''Verify''' that all tests pass.

== No Proxy Enabled ==
* '''Repeat Connectivity Tests''' Verify that users that are not using the proxy will not be negatively impacted by the change.
** Either test on another computer that is not firewalled, or relax the firewall restrictions on the testing network. If using the reference gateway configuration, run the ''nat_forward_all.sh'' script to allow traffic through without going through a proxy.
** Disable the proxy as described above.
** Rerun the following list of test cases, which are described in the section above.
*** Viewer Initialization
*** Avatar Navigation and Movement
*** Avatar Communication
*** Asset Download Tests
*** Asset Upload Tests
*** Integrated Web Browser
*** Media On a Prim
** '''Verify''' that all tests pass.
** '''Verify''' that overall viewer performance is approximately the same as usual for the machine you are testing on.
** Re-enable the firewall if you disabled it before further testing.

== SOCKS 5 with Username/Password Authentication ==
* '''Successful Login with SOCKS Authentication''' Test that the viewer can connect when the SOCKS 5 host requires a password.
** Enable both proxies, with "other" traffic going through SOCKS 5.
** Also in the proxy settings floater, select Username/Password as the SOCKS Authentication method.
** Enter your SOCKS 5 username and password in the appropriate fields. If you followed the reference gateway instructions, your linux username and password should work for the socks credentials.
** Select OK.
** Try to log in to Second Life.
** '''Verify''' that login is successful.
** Leave authentication enabled for the next test.
** Optional: The previous set of connectivity tests could be run in this mode as well to verify that the Username/Password authentication method works as well. This is a lower priority than the other three modes because this configuration is behaviorally very similar to the no authentication test, and should either connect or not connect.
* '''SOCKS 5 Password Security''' The SOCKS 5 password should not be stored in cleartext.
** Leave SOCKS 5 authentication enabled in the viewer from the previous test.
** Close all running instances of the viewer.
** Navigate to the user's Second Life settings directory.
** Search, using grep or ctrl-f in notepad depending on the platform, for the username and password you used to connect to the SOCKS 5 server in the previous step in the settings.xml that corresponds to the viewer version you are testing with (settings.xml if using a release version, settings_development.xml if using a development build, etc).
** '''Verify''' that the username and password do not appear in the settings files.
** Start the viewer and disable authentication.

----


= Pass/Fail Criteria =
* '''Passes''' if
** No unexpected behaviors are observed
* '''Fails''' if
** Deviation from expected behavior is observed
** A bug is detected that was not accounted for by this test plan
** Performance degradation is observed when the proxy is disabled.
* '''Known Issues'''
** SLVoice does not support proxies, therefore voice is not expected to work when running the viewer behind a strict firewall that blocks the ports used for voice communication. If voice is enabled, an error message will appear when the viewer fails to connect to the voice server.

= Tear Down =
* Disable all proxies in the viewer configuration.
* Disable the built-in browser.

User:Log Linden/Socks5Viewer/TestPlan

2011-08-19T20:05:46Z

Log Linden: /* Avatar Communication */

[[Category:Test Scripts]]
{| cellspacing="0" cellpadding="0" style="clear: {{{clear|right}}}; margin-bottom: .5em; float: right; padding: .5em 0 .8em 1.4em; background: none; width: {{{width|{{{1|auto}}}}}};" {{*if:{{{limit|}}}|class="toclimit-{{{limit}}}"}}
| __TOC__
|}
= Scope =
* This test is to verify that newly added proxy support in the viewer works as expected.
* The user story that prompted the changes is [https://jira.secondlife.com/browse/STORM-1112 STORM-1112 ].
* This test will only be meaningful if performed in a network environment that does not have access to second life.
* The test also requires a working web proxy host and SOCKS 5 proxy host.
* Estimated running time: 3 hours/platform after securing the appropriate test environment.

= Set-up =
== Environment ==
* Viewer: This test requires a build of the viewer that contains the LLProxy code. Grab the latest for your platform from the link below:
{{ViewerInstallers|{{JiraIssue|STORM-1112|Implement SOCKS 5 proxy}}| Allow the Second Life Viewer to connect through a SOCKS 5 proxy. |task=log_viewer-socks5|repo=https://bitbucket.org/log_linden/viewer_socks5}}
* Server: The test requires testing of mesh upload and download functionality, so access to a region with mesh support is required. Agni or Aditi are each fine. Region crossing will also be tested, so adjacent regions to test in will also be required.
* A restrictive, firewalled network to connect the testing machine to is required to obtain valid test results.
* A working web proxy host and a working SOCKS 5 host are required to complete the test.
* Instructions to set up a reference Ubuntu Linux server that will act as a firewall and proxy gateway [[User:Log_Linden/Socks5Viewer/TestPlan/ProxyGateway | are available]].
* While 3rd party testers are welcome to set up a duplicate of our reference gateway server, we are also interested in results you might get in your organization's specific network setup, rather than using our reference setup. Since you might not be allowed to reconfigure your organization's firewall or proxy host, feel free to only test in the proxy configuration your organization supports and report on results you observe.

== Other ==
* Second Life account that is able to upload mesh assets on the grid being tested.
* Your avatar should be a member of a group and be allowed to send messages in that group for testing.
* Part of the test is making sure land parcel media is functional. Find somewhere in world that has botha
* Sandbox, or other area where building is allowed.
* Enable advanced mode. The proxy options are not available in basic mode.
* Have a test image file, sound file, and collada model available to test upload functionality. A sample collada model is available from the [collada.org website | https://collada.org/owl/download.php?sess=0&parent=126&expand=1&order=name&curview=0&binary=1&id=698/ ].
* To test the gpu_table and feature_table download functionality of the viewer, a packet capture tool on the proxy host such as wireshark or tcp_dup is necessary to verify that the request tool is making use of the proxy. This might not be possible if you do not have access to your organization's proxy host.

= Common Procedures =
Refer to this section when asked to do one of the following in a test step.
* '''Enable proxy connection with HTTP traffic sent through web proxy.'''
** Change these settings before logging into Second Life.
** Open the Proxy settings floater. Me->Preferences->Setup->"Adjust Proxy Settings"
** Check "Use HTTP Proxy for Web pages" and enter the address and port number.
** Check "Use SOCKS 5 Proxy for UDP traffic" and enter the address and port number.
** Under other HTTP traffic proxy, select "Use HTTP Proxy".
** Click OK.

* '''Enable proxy connection with HTTP traffic sent through SOCKS 5 proxy.'''
** Change these settings before logging into Second Life.
** Open the Proxy settings floater. Me->Preferences->Setup->"Adjust Proxy Settings"
** Check "Use HTTP Proxy for Web pages" and enter the address and port number.
** Check "Use SOCKS 5 Proxy for UDP traffic" and enter the address and port number.
** Under other HTTP traffic proxy, select "Use SOCKS 5 Proxy".
** Click OK.

* '''Disable all proxies'''
** Change these settings before logging into Second Life.
** Open the Proxy settings floater. Me->Preferences->Setup->"Adjust Proxy Settings"
** Uncheck "Use HTTP Proxy for Web pages".
** Uncheck "Use SOCKS 5 Proxy for UDP traffic".
** Click OK.

* '''Clear Viewer Caches'''
** Click the "Clear Cache" button on the advanced tab of the preferences floater.
** Confirm that you want to clear the cache.
** Restart the Viewer.

= Test Steps =
== Configuration Consistency Checks ==
* '''Expected Defaults''' Check the default configuration.
** Install a version of the viewer that supports LLProxy communication.
** Start the viewer that was installed, but do not log in.
** Navigate to the proxy control floater (Me->Preferences->Setup->Adjust proxy Settings.
** Inspect the settings.
** '''Verify''' that both proxies are disabled.
** Leave this floater open for the next test.
* '''Invalid HTTP Proxy Configuration Error-Handling''' Test HTTP via socks when socks is disabled.
** Enable both proxies, enter valid information for both proxies.
** Change the "Other HTTP traffic proxy" option to "Use SOCKS 5 proxy".
** Quit the viewer.
** Edit the settings.xml file that corresponds to the channel of the viewer you are using to test with (e.g. settings_developer.xml, settings.xml, settings_beta.xml, etc.).
** Change the value of Socks5ProxyEnabled to "0". The block should look like the following:
<xml>
<key>Socks5ProxyEnabled</key>
<map>
<key>Comment</key>
<string>Use Socks5 Proxy</string>
<key>Persist</key>
<integer>1</integer>
<key>Type</key>
<string>Boolean</string>
<key>Value</key>
<integer>0</integer>
</map>
</xml>
** Restart the viewer.
** '''Verify''' that the viewer doesn't crash
** Open the proxy preferences floater.
** '''Verify''' that the "Other HTTP traffic" proxy option is now set to '''Do not proxy''.'
** Quit the viewer.
** '''Verify''' that Secondlife.log contains the following warning:
"Invalid other HTTP proxy configuration."
* '''Invalid Authentication Configuration Error-Handling.''' Test that an unexpected authentication method will not crash the viewer.
** Before starting the viewer, replace the block controlling the Socks5AuthType in settings.xml with another with a fake value. The following block should work.
<xml>
<key>Socks5AuthType</key>
<map>
<key>Comment</key>
<string>Selected Auth mechanism for Socks5</string>
<key>Persist</key>
<integer>1</integer>
<key>Type</key>
<string>String</string>
<key>Value</key>
<string>FakeAuth</string>
</map>
</xml>
** Start the viewer, but do not log in.
** '''Verify''' that the viewer doesn't crash.
** '''Verify''' that in the settings proxy floater, that authentication is disabled.
** Close the viewer.
** '''Verify''' that Secondlife.log contains the following warning:
"Invalid SOCKS 5 authentication type."

== Proxy Enabled, other HTTP through Web Proxy ==
* Follow the instructions above to enable the proxy and send HTTP traffic through the web proxy.
* This should be run with the firewall fully enabled to ensure the only traffic is being sent through the proxy.
* '''Verify''' that you are able to successfully log into Second Life.

=== Viewer Initialization ===
* '''HTTP Tables Loading''' Verify that the viewer is able to fetch the GPU table and feature table via the proxy.
** The proxy should be enabled before starting this test.
** Close the viewer.
** Start a packet capture on the proxy host that captures on all interfaces. Note: Even if you are unable to use packet filtering software, complete the test and verify that the error strings below are not in the log file.
** Start the viewer but do not log in.
** Inspect the capture for an HTTP request for an HTTP GET for a file of the form gpu_table.X.Y.Z.txt and for featuretable.X.Y.Z.txt.
** '''Verify''' that there was a request originating from the test machine for each of these files, and a subsequent request from the proxy host for the same files. It is normal for each of these requests to receive a 404 response.
** Close the viewer.
** Inspect the Secondlife.log file.
** '''Verify''' that there are no logs matching the following in Secondlife.log.
2011-08-18T21:42:07Z WARNING: LLURLRequest::process_impl: URLRequest Error: 56, Failure when receiving data from the peer, http://viewer-settings.secondlife.com/featuretable_xp.3.0.1.238013.txt
2011-08-18T21:42:07Z INFO: LLPumpIO::processChain: Pump generated pipe err: 'STATUS_ERROR'
2011-08-18T21:42:07Z WARNING: LLURLRequest::process_impl: URLRequest Error: 56, Failure when receiving data from the peer, http://viewer-settings.secondlife.com/gpu_table.3.0.1.238013.txt
2011-08-18T21:42:07Z INFO: LLPumpIO::processChain: Pump generated pipe err: 'STATUS_ERROR'
* '''Login Screen Renders Correctly''' The logon screen should be able to load content from the web using the configured proxy.
** Start the viewer, but do not log in.
**'''Verify''' that the contents of the login screen are displayed.

=== Avatar Navigation and Movement ===
* '''Walking'''
** '''Verify''' that your avatar can move around the world.
* '''Sitting'''
** '''Verify''' that your avatar can sit on objects.
* '''Flying'''
** '''Verify''' that you can fly around the region.
* '''World Map'''
** Open the World Map Floater (World->World Map).
** '''Verify''' that map tiles load and display the layout of the surrounding regions.
** '''Verify''' that green dots representing avatars are displayed.
** Close the World Map.
* '''Minimap'''
** Open the Mini-Map Floater (World->Mini-Map).
** '''Verify''' that map tiles are displayed.
* '''Region Crossing'''
** Fly or walk across a region boundary.
** '''Verify''' that you successfully arrive in the other region.
* '''Intra-region teleport'''
** Teleport by double clicking in the World Map floater, within the current region.
** '''Verify''' that you arrive in the place you clicked.
* '''Inter-region teleport'''
** Teleport by double clicking in the World Map floater, somewhere other than the current region.
** '''Verify''' that you arrive in the new region.

=== Avatar Communication ===
* '''Local Chat'''
** Try sending messages to others avatars standing nearby.
** '''Verify''' that the other people receive your messages
** '''Verify''' that you can receive messages from other people.
* '''Group Chat'''
** Try sending messages to a group chat channel.
** '''Verify''' that you can send messages
** '''Verify''' that you are receiving group chat messages.
* '''IM'''
** Try sending private IM messages to another avatar.
** '''Verify''' that the other avatar receives your messages
** '''Verify''' that you are able to receive their response.
* '''Display Names'''
** '''Verify''' that custom display names are visible for avatars that have them set.
** '''Verify''' that the display names of avatars are visible in your friends list.

=== Asset Download Tests ===
* Before starting this test, clear your viewer cache and relog.
* '''Texture'''
** '''Verify''' that textures load onto surfaces in your view.
* '''Sounds'''
** Locate the Button_click_down asset in your inventory. Double click the sound to play it.
** '''Verify''' that the sound plays.
* '''Notecard'''
** Locate the Community Standards notecard in the Library of your inventory.
** '''Verify''' that the notecard loads and is readable.
* '''Gestures'''
** Select a gesture from the "Gesture" menu at the bottom of the window.
** '''Verify''' that the gesture plays.
* '''Mesh'''
** Travel to a region with mesh assets available.
** '''Verify''' that the mesh assets rez and are visible.
* '''Legacy Fetch Methods'''
** Enable the Develop menu if you haven't already. (Me->Preferences->Advanced->Show Developer Menu)
** Disable HTTP Inventory and HTTP Textures in the Develop menu.
** Clear the viewer cache.
** Log back into Second Life.
** '''Verify''' that textures load onto surfaces in your view.
** '''Verify''' that your inventory loads.

=== Asset Creation Tests ===
* Move to a region where you have permission to build.
* '''Texture'''
** Upload a test image using the upload tool (Build->Upload->Image).
** When the upload is complete, apply that texture to an object.
** '''Verify''' that the image uploaded successfully.
* '''Sound'''
** Upload a test sound using the upload tool (Build->Upload->Sound)
** When the upload is complete, double click the sound in your inventory to play it back.
** '''Verify''' that the sound plays.
* '''Notecard'''
** In the inventory sidebar, click the "plus sign" (+) button at the bottom of the list of assets.
** In the menu that appears, select "New Notecard".
** Add some text in the body of the notecard and click save.
** Close the notecard
** Reopen the notecard from your inventory.
** '''Verify''' that the notecard text loads.
* '''Mesh'''
** Move to a mesh-enabled region.
** Select Build->Upload->Model to start the mesh upload process.
** In the file selection dialog, select the mesh object you prepared while setting up. The example file is named duck.dae.
** Select "Calculate weights & fee" at the bottom of the Upload Model dialog.
** After the upload fee has been calculated, select the "Upload" button.
** '''Verify''' that the mesh object is added to your inventory.
** Drag the mesh object out of your inventory onto the ground to rez it.
** '''Verify''' that the mesh object is rezzed.
* '''Object Creation'''
** Create a simple object using the build tools.
** '''Verify''' that the object is created
** '''Verify''' that you can take a copy of the created object into your inventory.
* '''Scripting'''
** Right click the object you created in the previous test and select edit.
** Select the content tab of the build floater.
** Click the New Script button.
** Double click the new script to edit.
** Edit the string "Hello, Avatar!" to be "Hi, Avatar!"
** Click save
** '''Verify''' that the script compiles.
** '''Verify''' that the object has sent the message "Hi, Avatar!".

=== Integrated Web Browser ===
* '''Browsing Test''' The integrated webkit browser should be able to browse while accessing the internet through a proxy.
** Enable the built-in browser. (Me->Preferences->Setup->"Use built-in browser", under "Web:").
** Enter a full url, like http://secondlife.com into text chat and send.
** Click the link in the text chat window.
** '''Verify''' that the built-in browser is able to access web content.

=== Media on a Prim ===
* '''Web Media'''
** '''Verify''' that web media is visible.
* '''Video Media'''
** '''Verify''' that video media is visible.

== Proxy Enabled, other HTTP through SOCKS 5 Proxy ==
* '''Repeat Connectivity Tests''' Verify that sending other HTTP traffic through the SOCKS 5 proxy works correctly.
** Configure the viewer as described in the '''Enable proxy connection with HTTP traffic sent through SOCKS 5 proxy.''' section above.
** '''Verify'' that you are able to successfully log into Second Life.
** Rerun the following list of test cases, which are described in the section above.
*** Viewer Initialization
*** Avatar Navigation and Movement
*** Avatar Communication
*** Asset Download Tests
*** Asset Upload Tests
*** Integrated Web Browser
*** Media On a Prim
** '''Verify''' that all tests pass.

== No Proxy Enabled ==
* '''Repeat Connectivity Tests''' Verify that users that are not using the proxy will not be negatively impacted by the change.
** Either test on another computer that is not firewalled, or relax the firewall restrictions on the testing network. If using the reference gateway configuration, run the ''nat_forward_all.sh'' script to allow traffic through without going through a proxy.
** Disable the proxy as described above.
** Rerun the following list of test cases, which are described in the section above.
*** Viewer Initialization
*** Avatar Navigation and Movement
*** Avatar Communication
*** Asset Download Tests
*** Asset Upload Tests
*** Integrated Web Browser
*** Media On a Prim
** '''Verify''' that all tests pass.
** '''Verify''' that overall viewer performance is approximately the same as usual for the machine you are testing on.
** Re-enable the firewall if you disabled it before further testing.

== SOCKS 5 with Username/Password Authentication ==
* '''Successful Login with SOCKS Authentication''' Test that the viewer can connect when the SOCKS 5 host requires a password.
** Enable both proxies, with "other" traffic going through SOCKS 5.
** Also in the proxy settings floater, select Username/Password as the SOCKS Authentication method.
** Enter your SOCKS 5 username and password in the appropriate fields. If you followed the reference gateway instructions, your linux username and password should work for the socks credentials.
** Select OK.
** Try to log in to Second Life.
** '''Verify''' that login is successful.
** Leave authentication enabled for the next test.
** Optional: The previous set of connectivity tests could be run in this mode as well to verify that the Username/Password authentication method works as well. This is a lower priority than the other three modes because this configuration is behaviorally very similar to the no authentication test, and should either connect or not connect.
* '''SOCKS 5 Password Security''' The SOCKS 5 password should not be stored in cleartext.
** Leave SOCKS 5 authentication enabled in the viewer from the previous test.
** Close all running instances of the viewer.
** Navigate to the user's Second Life settings directory.
** Search, using grep or ctrl-f in notepad depending on the platform, for the username and password you used to connect to the SOCKS 5 server in the previous step in the settings.xml that corresponds to the viewer version you are testing with (settings.xml if using a release version, settings_development.xml if using a development build, etc).
** '''Verify''' that the username and password do not appear in the settings files.
** Start the viewer and disable authentication.

----


= Pass/Fail Criteria =
* '''Passes''' if
** No unexpected behaviors are observed
* '''Fails''' if
** Deviation from expected behavior is observed
** A bug is detected that was not accounted for by this test plan
** Performance degradation is observed when the proxy is disabled.
* '''Known Issues'''
** SLVoice does not support proxies, therefore voice is not expected to work when running the viewer behind a strict firewall that blocks the ports used for voice communication. If voice is enabled, an error message will appear when the viewer fails to connect to the voice server.

= Tear Down =
* Disable all proxies in the viewer configuration.
* Disable the built-in browser.

User:Log Linden/Socks5Viewer/TestPlan

2011-08-19T19:44:30Z

Log Linden: capitalized http

[[Category:Test Scripts]]
{| cellspacing="0" cellpadding="0" style="clear: {{{clear|right}}}; margin-bottom: .5em; float: right; padding: .5em 0 .8em 1.4em; background: none; width: {{{width|{{{1|auto}}}}}};" {{*if:{{{limit|}}}|class="toclimit-{{{limit}}}"}}
| __TOC__
|}
= Scope =
* This test is to verify that newly added proxy support in the viewer works as expected.
* The user story that prompted the changes is [https://jira.secondlife.com/browse/STORM-1112 STORM-1112 ].
* This test will only be meaningful if performed in a network environment that does not have access to second life.
* The test also requires a working web proxy host and SOCKS 5 proxy host.
* Estimated running time: 3 hours/platform after securing the appropriate test environment.

= Set-up =
== Environment ==
* Viewer: This test requires a build of the viewer that contains the LLProxy code. Grab the latest for your platform from the link below:
{{ViewerInstallers|{{JiraIssue|STORM-1112|Implement SOCKS 5 proxy}}| Allow the Second Life Viewer to connect through a SOCKS 5 proxy. |task=log_viewer-socks5|repo=https://bitbucket.org/log_linden/viewer_socks5}}
* Server: The test requires testing of mesh upload and download functionality, so access to a region with mesh support is required. Agni or Aditi are each fine. Region crossing will also be tested, so adjacent regions to test in will also be required.
* A restrictive, firewalled network to connect the testing machine to is required to obtain valid test results.
* A working web proxy host and a working SOCKS 5 host are required to complete the test.
* Instructions to set up a reference Ubuntu Linux server that will act as a firewall and proxy gateway [[User:Log_Linden/Socks5Viewer/TestPlan/ProxyGateway | are available]].
* While 3rd party testers are welcome to set up a duplicate of our reference gateway server, we are also interested in results you might get in your organization's specific network setup, rather than using our reference setup. Since you might not be allowed to reconfigure your organization's firewall or proxy host, feel free to only test in the proxy configuration your organization supports and report on results you observe.

== Other ==
* Second Life account that is able to upload mesh assets on the grid being tested.
* Your avatar should be a member of a group and be allowed to send messages in that group for testing.
* Part of the test is making sure land parcel media is functional. Find somewhere in world that has botha
* Sandbox, or other area where building is allowed.
* Enable advanced mode. The proxy options are not available in basic mode.
* Have a test image file, sound file, and collada model available to test upload functionality. A sample collada model is available from the [collada.org website | https://collada.org/owl/download.php?sess=0&parent=126&expand=1&order=name&curview=0&binary=1&id=698/ ].
* To test the gpu_table and feature_table download functionality of the viewer, a packet capture tool on the proxy host such as wireshark or tcp_dup is necessary to verify that the request tool is making use of the proxy. This might not be possible if you do not have access to your organization's proxy host.

= Common Procedures =
Refer to this section when asked to do one of the following in a test step.
* '''Enable proxy connection with HTTP traffic sent through web proxy.'''
** Change these settings before logging into Second Life.
** Open the Proxy settings floater. Me->Preferences->Setup->"Adjust Proxy Settings"
** Check "Use HTTP Proxy for Web pages" and enter the address and port number.
** Check "Use SOCKS 5 Proxy for UDP traffic" and enter the address and port number.
** Under other HTTP traffic proxy, select "Use HTTP Proxy".
** Click OK.

* '''Enable proxy connection with HTTP traffic sent through SOCKS 5 proxy.'''
** Change these settings before logging into Second Life.
** Open the Proxy settings floater. Me->Preferences->Setup->"Adjust Proxy Settings"
** Check "Use HTTP Proxy for Web pages" and enter the address and port number.
** Check "Use SOCKS 5 Proxy for UDP traffic" and enter the address and port number.
** Under other HTTP traffic proxy, select "Use SOCKS 5 Proxy".
** Click OK.

* '''Disable all proxies'''
** Change these settings before logging into Second Life.
** Open the Proxy settings floater. Me->Preferences->Setup->"Adjust Proxy Settings"
** Uncheck "Use HTTP Proxy for Web pages".
** Uncheck "Use SOCKS 5 Proxy for UDP traffic".
** Click OK.

* '''Clear Viewer Caches'''
** Click the "Clear Cache" button on the advanced tab of the preferences floater.
** Confirm that you want to clear the cache.
** Restart the Viewer.

= Test Steps =
== Configuration Consistency Checks ==
* '''Expected Defaults''' Check the default configuration.
** Install a version of the viewer that supports LLProxy communication.
** Start the viewer that was installed, but do not log in.
** Navigate to the proxy control floater (Me->Preferences->Setup->Adjust proxy Settings.
** Inspect the settings.
** '''Verify''' that both proxies are disabled.
** Leave this floater open for the next test.
* '''Invalid HTTP Proxy Configuration Error-Handling''' Test HTTP via socks when socks is disabled.
** Enable both proxies, enter valid information for both proxies.
** Change the "Other HTTP traffic proxy" option to "Use SOCKS 5 proxy".
** Quit the viewer.
** Edit the settings.xml file that corresponds to the channel of the viewer you are using to test with (e.g. settings_developer.xml, settings.xml, settings_beta.xml, etc.).
** Change the value of Socks5ProxyEnabled to "0". The block should look like the following:
<xml>
<key>Socks5ProxyEnabled</key>
<map>
<key>Comment</key>
<string>Use Socks5 Proxy</string>
<key>Persist</key>
<integer>1</integer>
<key>Type</key>
<string>Boolean</string>
<key>Value</key>
<integer>0</integer>
</map>
</xml>
** Restart the viewer.
** '''Verify''' that the viewer doesn't crash
** Open the proxy preferences floater.
** '''Verify''' that the "Other HTTP traffic" proxy option is now set to '''Do not proxy''.'
** Quit the viewer.
** '''Verify''' that Secondlife.log contains the following warning:
"Invalid other HTTP proxy configuration."
* '''Invalid Authentication Configuration Error-Handling.''' Test that an unexpected authentication method will not crash the viewer.
** Before starting the viewer, replace the block controlling the Socks5AuthType in settings.xml with another with a fake value. The following block should work.
<xml>
<key>Socks5AuthType</key>
<map>
<key>Comment</key>
<string>Selected Auth mechanism for Socks5</string>
<key>Persist</key>
<integer>1</integer>
<key>Type</key>
<string>String</string>
<key>Value</key>
<string>FakeAuth</string>
</map>
</xml>
** Start the viewer, but do not log in.
** '''Verify''' that the viewer doesn't crash.
** '''Verify''' that in the settings proxy floater, that authentication is disabled.
** Close the viewer.
** '''Verify''' that Secondlife.log contains the following warning:
"Invalid SOCKS 5 authentication type."

== Proxy Enabled, other HTTP through Web Proxy ==
* Follow the instructions above to enable the proxy and send HTTP traffic through the web proxy.
* This should be run with the firewall fully enabled to ensure the only traffic is being sent through the proxy.
* '''Verify''' that you are able to successfully log into Second Life.

=== Viewer Initialization ===
* '''HTTP Tables Loading''' Verify that the viewer is able to fetch the GPU table and feature table via the proxy.
** The proxy should be enabled before starting this test.
** Close the viewer.
** Start a packet capture on the proxy host that captures on all interfaces. Note: Even if you are unable to use packet filtering software, complete the test and verify that the error strings below are not in the log file.
** Start the viewer but do not log in.
** Inspect the capture for an HTTP request for an HTTP GET for a file of the form gpu_table.X.Y.Z.txt and for featuretable.X.Y.Z.txt.
** '''Verify''' that there was a request originating from the test machine for each of these files, and a subsequent request from the proxy host for the same files. It is normal for each of these requests to receive a 404 response.
** Close the viewer.
** Inspect the Secondlife.log file.
** '''Verify''' that there are no logs matching the following in Secondlife.log.
2011-08-18T21:42:07Z WARNING: LLURLRequest::process_impl: URLRequest Error: 56, Failure when receiving data from the peer, http://viewer-settings.secondlife.com/featuretable_xp.3.0.1.238013.txt
2011-08-18T21:42:07Z INFO: LLPumpIO::processChain: Pump generated pipe err: 'STATUS_ERROR'
2011-08-18T21:42:07Z WARNING: LLURLRequest::process_impl: URLRequest Error: 56, Failure when receiving data from the peer, http://viewer-settings.secondlife.com/gpu_table.3.0.1.238013.txt
2011-08-18T21:42:07Z INFO: LLPumpIO::processChain: Pump generated pipe err: 'STATUS_ERROR'
* '''Login Screen Renders Correctly''' The logon screen should be able to load content from the web using the configured proxy.
** Start the viewer, but do not log in.
**'''Verify''' that the contents of the login screen are displayed.

=== Avatar Navigation and Movement ===
* '''Walking'''
** '''Verify''' that your avatar can move around the world.
* '''Sitting'''
** '''Verify''' that your avatar can sit on objects.
* '''Flying'''
** '''Verify''' that you can fly around the region.
* '''World Map'''
** Open the World Map Floater (World->World Map).
** '''Verify''' that map tiles load and display the layout of the surrounding regions.
** '''Verify''' that green dots representing avatars are displayed.
** Close the World Map.
* '''Minimap'''
** Open the Mini-Map Floater (World->Mini-Map).
** '''Verify''' that map tiles are displayed.
* '''Region Crossing'''
** Fly or walk across a region boundary.
** '''Verify''' that you successfully arrive in the other region.
* '''Intra-region teleport'''
** Teleport by double clicking in the World Map floater, within the current region.
** '''Verify''' that you arrive in the place you clicked.
* '''Inter-region teleport'''
** Teleport by double clicking in the World Map floater, somewhere other than the current region.
** '''Verify''' that you arrive in the new region.

=== Avatar Communication ===
* '''Local Chat'''
** Try sending messages to others avatars standing nearby.
** '''Verify''' that the other people receive your messages and that you can receive messages from them.
* '''Group Chat'''
** Try sending messages to a group chat channel.
** '''Verify''' that you can send messages and receive other messages.
* '''IM'''
** Try sending private IM messages to another avatar.
** '''Verify''' that the other avatar receives your messages, and that you are able to receive their response.
* '''Display Names'''
** '''Verify''' that custom display names are visible for avatars that have them set.

=== Asset Download Tests ===
* Before starting this test, clear your viewer cache and relog.
* '''Texture'''
** '''Verify''' that textures load onto surfaces in your view.
* '''Sounds'''
** Locate the Button_click_down asset in your inventory. Double click the sound to play it.
** '''Verify''' that the sound plays.
* '''Notecard'''
** Locate the Community Standards notecard in the Library of your inventory.
** '''Verify''' that the notecard loads and is readable.
* '''Gestures'''
** Select a gesture from the "Gesture" menu at the bottom of the window.
** '''Verify''' that the gesture plays.
* '''Mesh'''
** Travel to a region with mesh assets available.
** '''Verify''' that the mesh assets rez and are visible.
* '''Legacy Fetch Methods'''
** Enable the Develop menu if you haven't already. (Me->Preferences->Advanced->Show Developer Menu)
** Disable HTTP Inventory and HTTP Textures in the Develop menu.
** Clear the viewer cache.
** Log back into Second Life.
** '''Verify''' that textures load onto surfaces in your view.
** '''Verify''' that your inventory loads.

=== Asset Creation Tests ===
* Move to a region where you have permission to build.
* '''Texture'''
** Upload a test image using the upload tool (Build->Upload->Image).
** When the upload is complete, apply that texture to an object.
** '''Verify''' that the image uploaded successfully.
* '''Sound'''
** Upload a test sound using the upload tool (Build->Upload->Sound)
** When the upload is complete, double click the sound in your inventory to play it back.
** '''Verify''' that the sound plays.
* '''Notecard'''
** In the inventory sidebar, click the "plus sign" (+) button at the bottom of the list of assets.
** In the menu that appears, select "New Notecard".
** Add some text in the body of the notecard and click save.
** Close the notecard
** Reopen the notecard from your inventory.
** '''Verify''' that the notecard text loads.
* '''Mesh'''
** Move to a mesh-enabled region.
** Select Build->Upload->Model to start the mesh upload process.
** In the file selection dialog, select the mesh object you prepared while setting up. The example file is named duck.dae.
** Select "Calculate weights & fee" at the bottom of the Upload Model dialog.
** After the upload fee has been calculated, select the "Upload" button.
** '''Verify''' that the mesh object is added to your inventory.
** Drag the mesh object out of your inventory onto the ground to rez it.
** '''Verify''' that the mesh object is rezzed.
* '''Object Creation'''
** Create a simple object using the build tools.
** '''Verify''' that the object is created
** '''Verify''' that you can take a copy of the created object into your inventory.
* '''Scripting'''
** Right click the object you created in the previous test and select edit.
** Select the content tab of the build floater.
** Click the New Script button.
** Double click the new script to edit.
** Edit the string "Hello, Avatar!" to be "Hi, Avatar!"
** Click save
** '''Verify''' that the script compiles.
** '''Verify''' that the object has sent the message "Hi, Avatar!".

=== Integrated Web Browser ===
* '''Browsing Test''' The integrated webkit browser should be able to browse while accessing the internet through a proxy.
** Enable the built-in browser. (Me->Preferences->Setup->"Use built-in browser", under "Web:").
** Enter a full url, like http://secondlife.com into text chat and send.
** Click the link in the text chat window.
** '''Verify''' that the built-in browser is able to access web content.

=== Media on a Prim ===
* '''Web Media'''
** '''Verify''' that web media is visible.
* '''Video Media'''
** '''Verify''' that video media is visible.

== Proxy Enabled, other HTTP through SOCKS 5 Proxy ==
* '''Repeat Connectivity Tests''' Verify that sending other HTTP traffic through the SOCKS 5 proxy works correctly.
** Configure the viewer as described in the '''Enable proxy connection with HTTP traffic sent through SOCKS 5 proxy.''' section above.
** '''Verify'' that you are able to successfully log into Second Life.
** Rerun the following list of test cases, which are described in the section above.
*** Viewer Initialization
*** Avatar Navigation and Movement
*** Avatar Communication
*** Asset Download Tests
*** Asset Upload Tests
*** Integrated Web Browser
*** Media On a Prim
** '''Verify''' that all tests pass.

== No Proxy Enabled ==
* '''Repeat Connectivity Tests''' Verify that users that are not using the proxy will not be negatively impacted by the change.
** Either test on another computer that is not firewalled, or relax the firewall restrictions on the testing network. If using the reference gateway configuration, run the ''nat_forward_all.sh'' script to allow traffic through without going through a proxy.
** Disable the proxy as described above.
** Rerun the following list of test cases, which are described in the section above.
*** Viewer Initialization
*** Avatar Navigation and Movement
*** Avatar Communication
*** Asset Download Tests
*** Asset Upload Tests
*** Integrated Web Browser
*** Media On a Prim
** '''Verify''' that all tests pass.
** '''Verify''' that overall viewer performance is approximately the same as usual for the machine you are testing on.
** Re-enable the firewall if you disabled it before further testing.

== SOCKS 5 with Username/Password Authentication ==
* '''Successful Login with SOCKS Authentication''' Test that the viewer can connect when the SOCKS 5 host requires a password.
** Enable both proxies, with "other" traffic going through SOCKS 5.
** Also in the proxy settings floater, select Username/Password as the SOCKS Authentication method.
** Enter your SOCKS 5 username and password in the appropriate fields. If you followed the reference gateway instructions, your linux username and password should work for the socks credentials.
** Select OK.
** Try to log in to Second Life.
** '''Verify''' that login is successful.
** Leave authentication enabled for the next test.
** Optional: The previous set of connectivity tests could be run in this mode as well to verify that the Username/Password authentication method works as well. This is a lower priority than the other three modes because this configuration is behaviorally very similar to the no authentication test, and should either connect or not connect.
* '''SOCKS 5 Password Security''' The SOCKS 5 password should not be stored in cleartext.
** Leave SOCKS 5 authentication enabled in the viewer from the previous test.
** Close all running instances of the viewer.
** Navigate to the user's Second Life settings directory.
** Search, using grep or ctrl-f in notepad depending on the platform, for the username and password you used to connect to the SOCKS 5 server in the previous step in the settings.xml that corresponds to the viewer version you are testing with (settings.xml if using a release version, settings_development.xml if using a development build, etc).
** '''Verify''' that the username and password do not appear in the settings files.
** Start the viewer and disable authentication.

----


= Pass/Fail Criteria =
* '''Passes''' if
** No unexpected behaviors are observed
* '''Fails''' if
** Deviation from expected behavior is observed
** A bug is detected that was not accounted for by this test plan
** Performance degradation is observed when the proxy is disabled.
* '''Known Issues'''
** SLVoice does not support proxies, therefore voice is not expected to work when running the viewer behind a strict firewall that blocks the ports used for voice communication. If voice is enabled, an error message will appear when the viewer fails to connect to the voice server.

= Tear Down =
* Disable all proxies in the viewer configuration.
* Disable the built-in browser.

User:Log Linden/Socks5Viewer/TestPlan

2011-08-19T19:43:10Z

Log Linden: Fixed lists, converted all numbered lists to unordered list due to inability to include code blocks into steps.

[[Category:Test Scripts]]
{| cellspacing="0" cellpadding="0" style="clear: {{{clear|right}}}; margin-bottom: .5em; float: right; padding: .5em 0 .8em 1.4em; background: none; width: {{{width|{{{1|auto}}}}}};" {{*if:{{{limit|}}}|class="toclimit-{{{limit}}}"}}
| __TOC__
|}
= Scope =
* This test is to verify that newly added proxy support in the viewer works as expected.
* The user story that prompted the changes is [https://jira.secondlife.com/browse/STORM-1112 STORM-1112 ].
* This test will only be meaningful if performed in a network environment that does not have access to second life.
* The test also requires a working web proxy host and SOCKS 5 proxy host.
* Estimated running time: 3 hours/platform after securing the appropriate test environment.

= Set-up =
== Environment ==
* Viewer: This test requires a build of the viewer that contains the LLProxy code. Grab the latest for your platform from the link below:
{{ViewerInstallers|{{JiraIssue|STORM-1112|Implement SOCKS 5 proxy}}| Allow the Second Life Viewer to connect through a SOCKS 5 proxy. |task=log_viewer-socks5|repo=https://bitbucket.org/log_linden/viewer_socks5}}
* Server: The test requires testing of mesh upload and download functionality, so access to a region with mesh support is required. Agni or Aditi are each fine. Region crossing will also be tested, so adjacent regions to test in will also be required.
* A restrictive, firewalled network to connect the testing machine to is required to obtain valid test results.
* A working web proxy host and a working SOCKS 5 host are required to complete the test.
* Instructions to set up a reference Ubuntu Linux server that will act as a firewall and proxy gateway [[User:Log_Linden/Socks5Viewer/TestPlan/ProxyGateway | are available]].
* While 3rd party testers are welcome to set up a duplicate of our reference gateway server, we are also interested in results you might get in your organization's specific network setup, rather than using our reference setup. Since you might not be allowed to reconfigure your organization's firewall or proxy host, feel free to only test in the proxy configuration your organization supports and report on results you observe.

== Other ==
* Second Life account that is able to upload mesh assets on the grid being tested.
* Your avatar should be a member of a group and be allowed to send messages in that group for testing.
* Part of the test is making sure land parcel media is functional. Find somewhere in world that has botha
* Sandbox, or other area where building is allowed.
* Enable advanced mode. The proxy options are not available in basic mode.
* Have a test image file, sound file, and collada model available to test upload functionality. A sample collada model is available from the [collada.org website | https://collada.org/owl/download.php?sess=0&parent=126&expand=1&order=name&curview=0&binary=1&id=698/ ].
* To test the gpu_table and feature_table download functionality of the viewer, a packet capture tool on the proxy host such as wireshark or tcp_dup is necessary to verify that the request tool is making use of the proxy. This might not be possible if you do not have access to your organization's proxy host.

= Common Procedures =
Refer to this section when asked to do one of the following in a test step.
* '''Enable proxy connection with HTTP traffic sent through web proxy.'''
** Change these settings before logging into Second Life.
** Open the Proxy settings floater. Me->Preferences->Setup->"Adjust Proxy Settings"
** Check "Use HTTP Proxy for Web pages" and enter the address and port number.
** Check "Use SOCKS 5 Proxy for UDP traffic" and enter the address and port number.
** Under other HTTP traffic proxy, select "Use HTTP Proxy".
** Click OK.

* '''Enable proxy connection with HTTP traffic sent through SOCKS 5 proxy.'''
** Change these settings before logging into Second Life.
** Open the Proxy settings floater. Me->Preferences->Setup->"Adjust Proxy Settings"
** Check "Use HTTP Proxy for Web pages" and enter the address and port number.
** Check "Use SOCKS 5 Proxy for UDP traffic" and enter the address and port number.
** Under other HTTP traffic proxy, select "Use SOCKS 5 Proxy".
** Click OK.

* '''Disable all proxies'''
** Change these settings before logging into Second Life.
** Open the Proxy settings floater. Me->Preferences->Setup->"Adjust Proxy Settings"
** Uncheck "Use HTTP Proxy for Web pages".
** Uncheck "Use SOCKS 5 Proxy for UDP traffic".
** Click OK.

* '''Clear Viewer Caches'''
** Click the "Clear Cache" button on the advanced tab of the preferences floater.
** Confirm that you want to clear the cache.
** Restart the Viewer.

= Test Steps =
== Configuration Consistency Checks ==
* '''Expected Defaults''' Check the default configuration.
** Install a version of the viewer that supports LLProxy communication.
** Start the viewer that was installed, but do not log in.
** Navigate to the proxy control floater (Me->Preferences->Setup->Adjust proxy Settings.
** Inspect the settings.
** '''Verify''' that both proxies are disabled.
** Leave this floater open for the next test.
* '''Invalid HTTP Proxy Configuration Error-Handling''' Test http via socks when socks is disabled.
** Enable both proxies, enter valid information for both proxies.
** Change the "Other HTTP traffic proxy" option to "Use SOCKS 5 proxy".
** Quit the viewer.
** Edit the settings.xml file that corresponds to the channel of the viewer you are using to test with (e.g. settings_developer.xml, settings.xml, settings_beta.xml, etc.).
** Change the value of Socks5ProxyEnabled to "0". The block should look like the following:
<xml>
<key>Socks5ProxyEnabled</key>
<map>
<key>Comment</key>
<string>Use Socks5 Proxy</string>
<key>Persist</key>
<integer>1</integer>
<key>Type</key>
<string>Boolean</string>
<key>Value</key>
<integer>0</integer>
</map>
</xml>
** Restart the viewer.
** '''Verify''' that the viewer doesn't crash
** Open the proxy preferences floater.
** '''Verify''' that the "Other HTTP traffic" proxy option is now set to '''Do not proxy''.'
** Quit the viewer.
** '''Verify''' that Secondlife.log contains the following warning:
"Invalid other HTTP proxy configuration."
* '''Invalid Authentication Configuration Error-Handling.''' Test that an unexpected authentication method will not crash the viewer.
** Before starting the viewer, replace the block controlling the Socks5AuthType in settings.xml with another with a fake value. The following block should work.
<xml>
<key>Socks5AuthType</key>
<map>
<key>Comment</key>
<string>Selected Auth mechanism for Socks5</string>
<key>Persist</key>
<integer>1</integer>
<key>Type</key>
<string>String</string>
<key>Value</key>
<string>FakeAuth</string>
</map>
</xml>
** Start the viewer, but do not log in.
** '''Verify''' that the viewer doesn't crash.
** '''Verify''' that in the settings proxy floater, that authentication is disabled.
** Close the viewer.
** '''Verify''' that Secondlife.log contains the following warning:
"Invalid SOCKS 5 authentication type."

== Proxy Enabled, other HTTP through Web Proxy ==
* Follow the instructions above to enable the proxy and send HTTP traffic through the web proxy.
* This should be run with the firewall fully enabled to ensure the only traffic is being sent through the proxy.
* '''Verify''' that you are able to successfully log into Second Life.

=== Viewer Initialization ===
* '''HTTP Tables Loading''' Verify that the viewer is able to fetch the GPU table and feature table via the proxy.
** The proxy should be enabled before starting this test.
** Close the viewer.
** Start a packet capture on the proxy host that captures on all interfaces. Note: Even if you are unable to use packet filtering software, complete the test and verify that the error strings below are not in the log file.
** Start the viewer but do not log in.
** Inspect the capture for an HTTP request for an HTTP GET for a file of the form gpu_table.X.Y.Z.txt and for featuretable.X.Y.Z.txt.
** '''Verify''' that there was a request originating from the test machine for each of these files, and a subsequent request from the proxy host for the same files. It is normal for each of these requests to receive a 404 response.
** Close the viewer.
** Inspect the Secondlife.log file.
** '''Verify''' that there are no logs matching the following in Secondlife.log.
2011-08-18T21:42:07Z WARNING: LLURLRequest::process_impl: URLRequest Error: 56, Failure when receiving data from the peer, http://viewer-settings.secondlife.com/featuretable_xp.3.0.1.238013.txt
2011-08-18T21:42:07Z INFO: LLPumpIO::processChain: Pump generated pipe err: 'STATUS_ERROR'
2011-08-18T21:42:07Z WARNING: LLURLRequest::process_impl: URLRequest Error: 56, Failure when receiving data from the peer, http://viewer-settings.secondlife.com/gpu_table.3.0.1.238013.txt
2011-08-18T21:42:07Z INFO: LLPumpIO::processChain: Pump generated pipe err: 'STATUS_ERROR'
* '''Login Screen Renders Correctly''' The logon screen should be able to load content from the web using the configured proxy.
** Start the viewer, but do not log in.
**'''Verify''' that the contents of the login screen are displayed.

=== Avatar Navigation and Movement ===
* '''Walking'''
** '''Verify''' that your avatar can move around the world.
* '''Sitting'''
** '''Verify''' that your avatar can sit on objects.
* '''Flying'''
** '''Verify''' that you can fly around the region.
* '''World Map'''
** Open the World Map Floater (World->World Map).
** '''Verify''' that map tiles load and display the layout of the surrounding regions.
** '''Verify''' that green dots representing avatars are displayed.
** Close the World Map.
* '''Minimap'''
** Open the Mini-Map Floater (World->Mini-Map).
** '''Verify''' that map tiles are displayed.
* '''Region Crossing'''
** Fly or walk across a region boundary.
** '''Verify''' that you successfully arrive in the other region.
* '''Intra-region teleport'''
** Teleport by double clicking in the World Map floater, within the current region.
** '''Verify''' that you arrive in the place you clicked.
* '''Inter-region teleport'''
** Teleport by double clicking in the World Map floater, somewhere other than the current region.
** '''Verify''' that you arrive in the new region.

=== Avatar Communication ===
* '''Local Chat'''
** Try sending messages to others avatars standing nearby.
** '''Verify''' that the other people receive your messages and that you can receive messages from them.
* '''Group Chat'''
** Try sending messages to a group chat channel.
** '''Verify''' that you can send messages and receive other messages.
* '''IM'''
** Try sending private IM messages to another avatar.
** '''Verify''' that the other avatar receives your messages, and that you are able to receive their response.
* '''Display Names'''
** '''Verify''' that custom display names are visible for avatars that have them set.

=== Asset Download Tests ===
* Before starting this test, clear your viewer cache and relog.
* '''Texture'''
** '''Verify''' that textures load onto surfaces in your view.
* '''Sounds'''
** Locate the Button_click_down asset in your inventory. Double click the sound to play it.
** '''Verify''' that the sound plays.
* '''Notecard'''
** Locate the Community Standards notecard in the Library of your inventory.
** '''Verify''' that the notecard loads and is readable.
* '''Gestures'''
** Select a gesture from the "Gesture" menu at the bottom of the window.
** '''Verify''' that the gesture plays.
* '''Mesh'''
** Travel to a region with mesh assets available.
** '''Verify''' that the mesh assets rez and are visible.
* '''Legacy Fetch Methods'''
** Enable the Develop menu if you haven't already. (Me->Preferences->Advanced->Show Developer Menu)
** Disable HTTP Inventory and HTTP Textures in the Develop menu.
** Clear the viewer cache.
** Log back into Second Life.
** '''Verify''' that textures load onto surfaces in your view.
** '''Verify''' that your inventory loads.

=== Asset Creation Tests ===
* Move to a region where you have permission to build.
* '''Texture'''
** Upload a test image using the upload tool (Build->Upload->Image).
** When the upload is complete, apply that texture to an object.
** '''Verify''' that the image uploaded successfully.
* '''Sound'''
** Upload a test sound using the upload tool (Build->Upload->Sound)
** When the upload is complete, double click the sound in your inventory to play it back.
** '''Verify''' that the sound plays.
* '''Notecard'''
** In the inventory sidebar, click the "plus sign" (+) button at the bottom of the list of assets.
** In the menu that appears, select "New Notecard".
** Add some text in the body of the notecard and click save.
** Close the notecard
** Reopen the notecard from your inventory.
** '''Verify''' that the notecard text loads.
* '''Mesh'''
** Move to a mesh-enabled region.
** Select Build->Upload->Model to start the mesh upload process.
** In the file selection dialog, select the mesh object you prepared while setting up. The example file is named duck.dae.
** Select "Calculate weights & fee" at the bottom of the Upload Model dialog.
** After the upload fee has been calculated, select the "Upload" button.
** '''Verify''' that the mesh object is added to your inventory.
** Drag the mesh object out of your inventory onto the ground to rez it.
** '''Verify''' that the mesh object is rezzed.
* '''Object Creation'''
** Create a simple object using the build tools.
** '''Verify''' that the object is created
** '''Verify''' that you can take a copy of the created object into your inventory.
* '''Scripting'''
** Right click the object you created in the previous test and select edit.
** Select the content tab of the build floater.
** Click the New Script button.
** Double click the new script to edit.
** Edit the string "Hello, Avatar!" to be "Hi, Avatar!"
** Click save
** '''Verify''' that the script compiles.
** '''Verify''' that the object has sent the message "Hi, Avatar!".

=== Integrated Web Browser ===
* '''Browsing Test''' The integrated webkit browser should be able to browse while accessing the internet through a proxy.
** Enable the built-in browser. (Me->Preferences->Setup->"Use built-in browser", under "Web:").
** Enter a full url, like http://secondlife.com into text chat and send.
** Click the link in the text chat window.
** '''Verify''' that the built-in browser is able to access web content.

=== Media on a Prim ===
* '''Web Media'''
** '''Verify''' that web media is visible.
* '''Video Media'''
** '''Verify''' that video media is visible.

== Proxy Enabled, other HTTP through SOCKS 5 Proxy ==
* '''Repeat Connectivity Tests''' Verify that sending other HTTP traffic through the SOCKS 5 proxy works correctly.
** Configure the viewer as described in the '''Enable proxy connection with HTTP traffic sent through SOCKS 5 proxy.''' section above.
** '''Verify'' that you are able to successfully log into Second Life.
** Rerun the following list of test cases, which are described in the section above.
*** Viewer Initialization
*** Avatar Navigation and Movement
*** Avatar Communication
*** Asset Download Tests
*** Asset Upload Tests
*** Integrated Web Browser
*** Media On a Prim
** '''Verify''' that all tests pass.

== No Proxy Enabled ==
* '''Repeat Connectivity Tests''' Verify that users that are not using the proxy will not be negatively impacted by the change.
** Either test on another computer that is not firewalled, or relax the firewall restrictions on the testing network. If using the reference gateway configuration, run the ''nat_forward_all.sh'' script to allow traffic through without going through a proxy.
** Disable the proxy as described above.
** Rerun the following list of test cases, which are described in the section above.
*** Viewer Initialization
*** Avatar Navigation and Movement
*** Avatar Communication
*** Asset Download Tests
*** Asset Upload Tests
*** Integrated Web Browser
*** Media On a Prim
** '''Verify''' that all tests pass.
** '''Verify''' that overall viewer performance is approximately the same as usual for the machine you are testing on.
** Re-enable the firewall if you disabled it before further testing.

== SOCKS 5 with Username/Password Authentication ==
* '''Successful Login with SOCKS Authentication''' Test that the viewer can connect when the SOCKS 5 host requires a password.
** Enable both proxies, with "other" traffic going through SOCKS 5.
** Also in the proxy settings floater, select Username/Password as the SOCKS Authentication method.
** Enter your SOCKS 5 username and password in the appropriate fields. If you followed the reference gateway instructions, your linux username and password should work for the socks credentials.
** Select OK.
** Try to log in to Second Life.
** '''Verify''' that login is successful.
** Leave authentication enabled for the next test.
** Optional: The previous set of connectivity tests could be run in this mode as well to verify that the Username/Password authentication method works as well. This is a lower priority than the other three modes because this configuration is behaviorally very similar to the no authentication test, and should either connect or not connect.
* '''SOCKS 5 Password Security''' The SOCKS 5 password should not be stored in cleartext.
** Leave SOCKS 5 authentication enabled in the viewer from the previous test.
** Close all running instances of the viewer.
** Navigate to the user's Second Life settings directory.
** Search, using grep or ctrl-f in notepad depending on the platform, for the username and password you used to connect to the SOCKS 5 server in the previous step in the settings.xml that corresponds to the viewer version you are testing with (settings.xml if using a release version, settings_development.xml if using a development build, etc).
** '''Verify''' that the username and password do not appear in the settings files.
** Start the viewer and disable authentication.

----


= Pass/Fail Criteria =
* '''Passes''' if
** No unexpected behaviors are observed
* '''Fails''' if
** Deviation from expected behavior is observed
** A bug is detected that was not accounted for by this test plan
** Performance degradation is observed when the proxy is disabled.
* '''Known Issues'''
** SLVoice does not support proxies, therefore voice is not expected to work when running the viewer behind a strict firewall that blocks the ports used for voice communication. If voice is enabled, an error message will appear when the viewer fails to connect to the voice server.

= Tear Down =
* Disable all proxies in the viewer configuration.
* Disable the built-in browser.

User:Log Linden/Socks5Viewer/TestPlan

2011-08-19T18:51:42Z

Log Linden:

[[Category:Test Scripts]]
{| cellspacing="0" cellpadding="0" style="clear: {{{clear|right}}}; margin-bottom: .5em; float: right; padding: .5em 0 .8em 1.4em; background: none; width: {{{width|{{{1|auto}}}}}};" {{#if:{{{limit|}}}|class="toclimit-{{{limit}}}"}}
| __TOC__
|}
= Scope =
* This test is to verify that newly added proxy support in the viewer works as expected.
* The user story that prompted the changes is [https://jira.secondlife.com/browse/STORM-1112 STORM-1112 ].
* This test will only be meaningful if performed in a network environment that does not have access to second life.
* The test also requires a working web proxy host and SOCKS 5 proxy host.
* Estimated running time: 3 hours/platform after securing the appropriate test environment.

= Set-up =
== Environment ==
* Viewer: This test requires a build of the viewer that contains the LLProxy code. Grab the latest for your platform from the link below:
{{ViewerInstallers|{{JiraIssue|STORM-1112|Implement SOCKS 5 proxy}}| Allow the Second Life Viewer to connect through a SOCKS 5 proxy. |task=log_viewer-socks5|repo=https://bitbucket.org/log_linden/viewer_socks5}}
* Server: The test requires testing of mesh upload and download functionality, so access to a region with mesh support is required. Agni or Aditi are each fine. Region crossing will also be tested, so adjacent regions to test in will also be required.
* A restrictive, firewalled network to connect the testing machine to is required to obtain valid test results.
* A working web proxy host and a working SOCKS 5 host are required to complete the test.
* Instructions to set up a reference Ubuntu Linux server that will act as a firewall and proxy gateway [[User:Log_Linden/Socks5Viewer/TestPlan/ProxyGateway | are available]].
* While 3rd party testers are welcome to set up a duplicate of our reference gateway server, we are also interested in results you might get in your organization's specific network setup, rather than using our reference setup. Since you might not be allowed to reconfigure your organization's firewall or proxy host, feel free to only test in the proxy configuration your organization supports and report on results you observe.

== Other ==
* Second Life account that is able to upload mesh assets on the grid being tested.
* Your avatar should be a member of a group and be allowed to send messages in that group for testing.
* Part of the test is making sure land parcel media is functional. Find somewhere in world that has botha
* Sandbox, or other area where building is allowed.
* Enable advanced mode. The proxy options are not available in basic mode.
* Have a test image file, sound file, and collada model available to test upload functionality. A sample collada model is available from the [collada.org website | https://collada.org/owl/download.php?sess=0&parent=126&expand=1&order=name&curview=0&binary=1&id=698/ ].
* To test the gpu_table and feature_table download functionality of the viewer, a packet capture tool on the proxy host such as wireshark or tcp_dup is necessary to verify that the request tool is making use of the proxy. This might not be possible if you do not have access to your organization's proxy host.

= Common Procedures =
Refer to this section when asked to do one of the following in a test step.
* '''Enable proxy connection with HTTP traffic sent through web proxy.'''
*# Change these settings before logging into Second Life.
*# Open the Proxy settings floater. Me->Preferences->Setup->"Adjust Proxy Settings"
*# Check "Use HTTP Proxy for Web pages" and enter the address and port number.
*# Check "Use SOCKS 5 Proxy for UDP traffic" and enter the address and port number.
*# Under other HTTP traffic proxy, select "Use HTTP Proxy".
*# Click OK.

* '''Enable proxy connection with HTTP traffic sent through SOCKS 5 proxy.'''
*# Change these settings before logging into Second Life.
*# Open the Proxy settings floater. Me->Preferences->Setup->"Adjust Proxy Settings"
*# Check "Use HTTP Proxy for Web pages" and enter the address and port number.
*# Check "Use SOCKS 5 Proxy for UDP traffic" and enter the address and port number.
*# Under other HTTP traffic proxy, select "Use SOCKS 5 Proxy".
*# Click OK.

* '''Disable all proxies'''
*# Change these settings before logging into Second Life.
*# Open the Proxy settings floater. Me->Preferences->Setup->"Adjust Proxy Settings"
*# Uncheck "Use HTTP Proxy for Web pages".
*# Uncheck "Use SOCKS 5 Proxy for UDP traffic".
*# Click OK.

* '''Clear Viewer Caches'''
*# Click the "Clear Cache" button on the advanced tab of the preferences floater.
*# Confirm that you want to clear the cache.
*# Restart the Viewer.

= Test Steps =
== Configuration Consistency Checks ==
# '''Expected Defaults''' Check the default configuration.
## Install a version of the viewer that supports LLProxy communication.
## Start the viewer that was installed, but do not log in.
## Navigate to the proxy control floater (Me->Preferences->Setup->Adjust proxy Settings.
## Inspect the settings.
## '''Verify''' that both proxies are disabled.
## Leave this floater open for the next test.
# '''Invalid HTTP Proxy Configuration Error-Handling'''
## Enable both proxies, type in valid information for both proxies.
## Change the "Other HTTP traffic proxy" option to "Use SOCKS 5 proxy".
## Quit the viewer.
## Edit the settings.xml file that corresponds to the channel of the viewer you are using to test with (e.g. settings_developer.xml, settings.xml, settings_beta.xml, etc.).
## Change the value of Socks5ProxyEnabled to be "0". The block should look like the following.
<xml>
<key>Socks5ProxyEnabled</key>
<map>
<key>Comment</key>
<string>Use Socks5 Proxy</string>
<key>Persist</key>
<integer>1</integer>
<key>Type</key>
<string>Boolean</string>
<key>Value</key>
<integer>0</integer>
</map>
</xml>
##: Restart the viewer.
## '''Verify''' that the viewer doesn't crash
## Open the proxy preferences floater.
## '''Verify''' that the "Other HTTP traffic" proxy option is now set to '''Do not proxy''.'
## Quit the viewer.
## '''Verify''' that Secondlife.log contains the following warning:
"Invalid other HTTP proxy configuration."
# '''Invalid authentication configuration error-handling.''' Test that an unexpected authentication method will not crash the viewer.
## Before starting the viewer, replace the block controlling the Socks5AuthType in settings.xml with another with a fake value. The following block should work.
<xml>
<key>Socks5AuthType</key>
<map>
<key>Comment</key>
<string>Selected Auth mechanism for Socks5</string>
<key>Persist</key>
<integer>1</integer>
<key>Type</key>
<string>String</string>
<key>Value</key>
<string>FakeAuth</string>
</map>
</xml>
## Start the viewer, but do not log in.
## '''Verify''' that the viewer doesn't crash.
## '''Verify''' that in the settings proxy floater, that authentication is disabled.
## Close the viewer.
## '''Verify''' that Secondlife.log contains the following warning:
"Invalid SOCKS 5 authentication type."

== Proxy Enabled, other HTTP through Web Proxy ==
# Follow the instructions above to enable the proxy and send HTTP traffic through the web proxy.
# This should be run with the firewall fully enabled to ensure the only traffic is being sent through the proxy.
# '''Verify'' that you are able to successfully log into Second Life.

=== Viewer Initialization ===
# '''HTTP Tables Loading''' Verify that the viewer is able to fetch the GPU table and feature table via the proxy.
## The proxy should be enabled before starting this test.
## Close the viewer.
## Start a packet capture on the proxy host that captures on all interfaces. Note: Even if you are unable to use packet filtering software, complete the test and verify that the error strings below are not in the log file.
## Start the viewer but do not log in.
## Inspect the capture for an HTTP request for an HTTP GET for a file of the form gpu_table.X.Y.Z.txt and for featuretable.X.Y.Z.txt.
## '''Verify''' that there was a request originating from the test machine for each of these files, and a subsequent request from the proxy host for the same files. It is normal for each of these requests to receive a 404 response.
## Close the viewer.
## Inspect the Secondlife.log file.
## '''Verify''' that there are no logs matching the following in Secondlife.log.
2011-08-18T21:42:07Z WARNING: LLURLRequest::process_impl: URLRequest Error: 56, Failure when receiving data from the peer, http://viewer-settings.secondlife.com/featuretable_xp.3.0.1.238013.txt
2011-08-18T21:42:07Z INFO: LLPumpIO::processChain: Pump generated pipe err: 'STATUS_ERROR'
2011-08-18T21:42:07Z WARNING: LLURLRequest::process_impl: URLRequest Error: 56, Failure when receiving data from the peer, http://viewer-settings.secondlife.com/gpu_table.3.0.1.238013.txt
2011-08-18T21:42:07Z INFO: LLPumpIO::processChain: Pump generated pipe err: 'STATUS_ERROR'
# '''Login Screen Renders Correctly''' The logon screen should be able to load content from the web using the configured proxy.
## Start the viewer, but do not log in.
##'''Verify''' that the contents of the login screen are displayed.

=== Avatar Navigation and Movement ===
# '''Walking'''
## '''Verify''' that your avatar can move around the world.
# '''Sitting'''
## '''Verify''' that your avatar can sit on objects.
# '''Flying'''
## '''Verify''' that you can fly around the region.
# '''World Map'''
## Open the World Map Floater (World->World Map).
## '''Verify''' that map tiles load and display the layout of the surrounding regions.
## '''Verify''' that green dots representing avatars are displayed.
## Close the World Map.
# '''Minimap'''
## Open the Mini-Map Floater (World->Mini-Map).
## '''Verify''' that map tiles are displayed.
# '''Region Crossing'''
## Fly or walk across a region boundary.
## '''Verify''' that you successfully arrive in the other region.
# '''Intra-region teleport'''
## Teleport by double clicking in the World Map floater, within the current region.
## '''Verify''' that you arrive in the place you clicked.
# '''Inter-region teleport'''
## Teleport by double clicking in the World Map floater, somewhere other than the current region.
## '''Verify''' that you arrive in the new region.

=== Avatar Communication ===
# '''Local Chat'''
## Try sending messages to others avatars standing nearby.
## '''Verify''' that the other people receive your messages and that you can receive messages from them.
# '''Group Chat'''
## Try sending messages to a group chat channel.
## '''Verify''' that you can send messages and receive other messages.
# '''IM'''
## Try sending private IM messages to another avatar.
## '''Verify''' that the other avatar receives your messages, and that you are able to receive their response.
# '''Display Names'''
## '''Verify''' that custom display names are visible for avatars that have them set.

=== Asset Download Tests ===
# Before starting this test, clear your viewer cache and relog.
# '''Texture'''
## '''Verify''' that textures load onto surfaces in your view.
# '''Sounds'''
## Locate the Button_click_down asset in your inventory. Double click the sound to play it.
## '''Verify''' that the sound plays.
# '''Notecard'''
## Locate the Community Standards notecard in the Library of your inventory.
## '''Verify''' that the notecard loads and is readable.
# '''Gestures'''
## Select a gesture from the "Gesture" menu at the bottom of the window.
## '''Verify''' that the gesture plays.
# '''Mesh'''
## Travel to a region with mesh assets available.
## '''Verify''' that the mesh assets rez and are visible.
# '''Legacy Fetch Methods'''
## Enable the Develop menu if you haven't already. (Me->Preferences->Advanced->Show Developer Menu)
## Disable HTTP Inventory and HTTP Textures in the Develop menu.
## Clear the viewer cache.
## Log back into Second Life.
## '''Verify''' that textures load onto surfaces in your view.
## '''Verify''' that your inventory loads.

=== Asset Creation Tests ===
# Move to a region where you have permission to build.
# '''Texture'''
## Upload a test image using the upload tool (Build->Upload->Image).
## When the upload is complete, apply that texture to an object.
## '''Verify''' that the image uploaded successfully.
# '''Sound'''
## Upload a test sound using the upload tool (Build->Upload->Sound)
## When the upload is complete, double click the sound in your inventory to play it back.
## '''Verify''' that the sound plays.
# '''Notecard'''
## In the inventory sidebar, click the "plus sign" (+) button at the bottom of the list of assets.
## In the menu that appears, select "New Notecard".
## Add some text in the body of the notecard and click save.
## Close the notecard
## Reopen the notecard from your inventory.
## '''Verify''' that the notecard text loads.
# '''Mesh'''
## Move to a mesh-enabled region.
## Select Build->Upload->Model to start the mesh upload process.
## In the file selection dialog, select the mesh object you prepared while setting up. The example file is named duck.dae.
## Select "Calculate weights & fee" at the bottom of the Upload Model dialog.
## After the upload fee has been calculated, select the "Upload" button.
## '''Verify''' that the mesh object is added to your inventory.
## Drag the mesh object out of your inventory onto the ground to rez it.
## '''Verify''' that the mesh object is rezzed.
# '''Object Creation'''
## Create a simple object using the build tools.
## '''Verify''' that the object is created
## '''Verify''' that you can take a copy of the created object into your inventory.
# '''Scripting'''
## Right click the object you created in the previous test and select edit.
## Select the content tab of the build floater.
## Click the New Script button.
## Double click the new script to edit.
## Edit the string "Hello, Avatar!" to be "Hi, Avatar!"
## Click save
## '''Verify''' that the script compiles.
## '''Verify''' that the object has sent the message "Hi, Avatar!".

=== Integrated Web Browser ===
# '''Browsing Test''' The integrated webkit browser should be able to browse while accessing the internet through a proxy.
## Enable the built-in browser. (Me->Preferences->Setup->"Use built-in browser", under "Web:").
## Enter a full url, like http://secondlife.com into text chat and send.
## Click the link in the text chat window.
## '''Verify''' that the built-in browser is able to access web content.

=== Media on a Prim ===
# '''Web Media'''
## '''Verify''' that web media is visible.
# '''Video Media'''
## '''Verify''' that video media is visible.

== Proxy Enabled, other HTTP through SOCKS 5 Proxy ==
# '''Repeat Connectivity Tests''' Verify that sending other HTTP traffic through the SOCKS 5 proxy works correctly.
## Configure the viewer as described in the '''Enable proxy connection with HTTP traffic sent through SOCKS 5 proxy.''' section above.
## '''Verify'' that you are able to successfully log into Second Life.
## Rerun the following list of test cases, which are described in the section above.
### Viewer Initialization
### Avatar Navigation and Movement
### Avatar Communication
### Asset Download Tests
### Asset Upload Tests
### Integrated Web Browser
### Media On a Prim
## '''Verify''' that all tests pass.

== No Proxy Enabled ==
# '''Repeat Connectivity Tests''' Verify that users that are not using the proxy will not be negatively impacted by the change.
## Either test on another computer that is not firewalled, or relax the firewall restrictions on the testing network. If using the reference gateway configuration, run the ''nat_forward_all.sh'' script to allow traffic through without going through a proxy.
## Disable the proxy as described above.
## Rerun the following list of test cases, which are described in the section above.
### Viewer Initialization
### Avatar Navigation and Movement
### Avatar Communication
### Asset Download Tests
### Asset Upload Tests
### Integrated Web Browser
### Media On a Prim
## '''Verify''' that all tests pass.
## '''Verify''' that overall viewer performance is approximately the same as usual for the machine you are testing on.
## Re-enable the firewall if you disabled it before further testing.

== SOCKS 5 with Username/Password Authentication ==
# '''Successful Login with SOCKS Authentication''' Test that the viewer can connect when the SOCKS 5 host requires a password.
## Enable both proxies, with "other" traffic going through SOCKS 5.
## Also in the proxy settings floater, select Username/Password as the SOCKS Authentication method.
## Enter your SOCKS 5 username and password in the appropriate fields. If you followed the reference gateway instructions, your linux username and password should work for the socks credentials.
## Select OK.
## Try to log in to Second Life.
## '''Verify''' that login is successful.
## Leave authentication enabled for the next test.
## Optional: The previous set of connectivity tests could be run in this mode as well to verify that the Username/Password authentication method works as well. This is a lower priority than the other three modes because this configuration is behaviorally very similar to the no authentication test, and should either connect or not connect.
# '''SOCKS 5 Password Security''' The SOCKS 5 password should not be stored in cleartext.
## Leave SOCKS 5 authentication enabled in the viewer from the previous test.
## Close all running instances of the viewer.
## Navigate to the user's Second Life settings directory.
## Search, using grep or ctrl-f in notepad depending on the platform, for the username and password you used to connect to the SOCKS 5 server in the previous step in the settings.xml that corresponds to the viewer version you are testing with (settings.xml if using a release version, settings_development.xml if using a development build, etc).
## '''Verify''' that the username and password do not appear in the settings files.
## Start the viewer and disable authentication.

----


= Pass/Fail Criteria =
# '''Passes''' if
## No unexpected behaviors are observed
# '''Fails''' if
## Deviation from expected behavior is observed
## A bug is detected that was not accounted for by this test plan
## Performance degradation is observed when the proxy is disabled.
# '''Known Issues'''
## SLVoice does not support proxies, therefore voice is not expected to work when running the viewer behind a strict firewall that blocks the ports used for voice communication. If voice is enabled, an error message will appear when the viewer fails to connect to the voice server.

= Tear Down =
* Disable all proxies in the viewer configuration.
* Disable the built-in browser.

User:Log Linden/Socks5Viewer/TestPlan

2011-08-18T21:51:05Z

Log Linden: Added http tables test.

[[Category:Test Scripts]]
{| cellspacing="0" cellpadding="0" style="clear: {{{clear|right}}}; margin-bottom: .5em; float: right; padding: .5em 0 .8em 1.4em; background: none; width: {{{width|{{{1|auto}}}}}};" {{#if:{{{limit|}}}|class="toclimit-{{{limit}}}"}}
| __TOC__
|}
= Scope =
* This test is to verify that newly added proxy support in the viewer works as expected.
* The user story that prompted the changes is [https://jira.secondlife.com/browse/STORM-1112 STORM-1112 ].
* This test will only be meaningful if performed in a network environment that does not have access to second life.
* The test also requires a working web proxy host and SOCKS 5 proxy host.
* Estimated running time: 3 hours/platform after securing the appropriate test environment.

= Set-up =
== Environment ==
* Viewer: This test requires a build of the viewer that contains the LLProxy code. Grab the latest for your platform from the link below:
{{ViewerInstallers|{{JiraIssue|STORM-1112|Implement SOCKS 5 proxy}}| Allow the Second Life Viewer to connect through a SOCKS 5 proxy. |task=log_viewer-socks5|repo=https://bitbucket.org/log_linden/viewer_socks5}}
* Server: The test requires testing of mesh upload and download functionality, so access to a region with mesh support is required. Agni or Aditi are each fine. Region crossing will also be tested, so adjacent regions to test in will also be required.
* A restrictive, firewalled network to connect the testing machine to is required to obtain valid test results.
* A working web proxy host and a working SOCKS 5 host are required to complete the test.
* Instructions to set up a reference Ubuntu Linux server that will act as a firewall and proxy gateway [[User:Log_Linden/Socks5Viewer/TestPlan/ProxyGateway | are available]].
* While 3rd party testers are welcome to set up a duplicate of our reference gateway server, we are also interested in results you might get in your organization's specific network setup, rather than using our reference setup. Since you might not be allowed to reconfigure your organization's firewall or proxy host, feel free to only test in the proxy configuration your organization supports and report on results you observe.

== Other ==
* Second Life account that is able to upload mesh assets on the grid being tested.
* Your avatar should be a member of a group and be allowed to send messages in that group for testing.
* Part of the test is making sure land parcel media is functional. Find somewhere in world that has botha
* Sandbox, or other area where building is allowed.
* Enable advanced mode. The proxy options are not available in basic mode.
* Have a test image file, sound file, and collada model available to test upload functionality. A sample collada model is available from the [collada.org website | https://collada.org/owl/download.php?sess=0&parent=126&expand=1&order=name&curview=0&binary=1&id=698/ ].
* To test the gpu_table and feature_table download functionality of the viewer, a packet capture tool on the proxy host such as wireshark or tcp_dup is necessary to verify that the request tool is making use of the proxy. This might not be possible if you do not have access to your organization's proxy host.

= Common Procedures =
Refer to this section when asked to do one of the following in a test step.
# '''Enable proxy connection with HTTP traffic sent through web proxy.'''
## Change these settings before logging into Second Life.
## Open the Proxy settings floater. Me->Preferences->Setup->"Adjust Proxy Settings"
## Check "Use HTTP Proxy for Web pages" and enter the address and port number.
## Check "Use SOCKS 5 Proxy for UDP traffic" and enter the address and port number.
## Under other HTTP traffic proxy, select "Use HTTP Proxy".
## Click OK.

# '''Enable proxy connection with HTTP traffic sent through SOCKS 5 proxy.'''
## Change these settings before logging into Second Life.
## Open the Proxy settings floater. Me->Preferences->Setup->"Adjust Proxy Settings"
## Check "Use HTTP Proxy for Web pages" and enter the address and port number.
## Check "Use SOCKS 5 Proxy for UDP traffic" and enter the address and port number.
## Under other HTTP traffic proxy, select "Use SOCKS 5 Proxy".
## Click OK.

# '''Disable all proxies'''
## Change these settings before logging into Second Life.
## Open the Proxy settings floater. Me->Preferences->Setup->"Adjust Proxy Settings"
## Uncheck "Use HTTP Proxy for Web pages".
## Uncheck "Use SOCKS 5 Proxy for UDP traffic".
## Click OK.

# '''Clear Viewer Caches'''
## Click the "Clear Cache" button on the advanced tab of the preferences floater.
## Confirm that you want to clear the cache.
## Restart the Viewer.

= Test Steps =
== Configuration Consistency Checks ==
# '''Expected Defaults''' Check the default configuration.
## Install a version of the viewer that supports LLProxy communication.
## Start the viewer that was installed, but do not log in.
## Navigate to the proxy control floater (Me->Preferences->Setup->Adjust proxy Settings.
## Inspect the settings.
## '''Verify''' that both proxies are disabled.
## Leave this floater open for the next test.
# '''Invalid HTTP Proxy Configuration Error-Handling'''
## Enable both proxies, type in valid information for both proxies.
## Change the "Other HTTP traffic proxy" option to "Use SOCKS 5 proxy".
## Quit the viewer.
## Edit the settings.xml file that corresponds to the channel of the viewer you are using to test with (e.g. settings_developer.xml, settings.xml, settings_beta.xml, etc.).
## Change the value of Socks5ProxyEnabled to be "0". The block should look like the following.
<xml>
<key>Socks5ProxyEnabled</key>
<map>
<key>Comment</key>
<string>Use Socks5 Proxy</string>
<key>Persist</key>
<integer>1</integer>
<key>Type</key>
<string>Boolean</string>
<key>Value</key>
<integer>0</integer>
</map>
</xml>
## Restart the viewer.
## '''Verify''' that the viewer doesn't crash
## Open the proxy preferences floater.
## '''Verify''' that the "Other HTTP traffic" proxy option is now set to '''Do not proxy''.'
## Quit the viewer.
## '''Verify''' that Secondlife.log contains the following warning:
"Invalid other HTTP proxy configuration."
# '''Invalid authentication configuration error-handling.''' Test that an unexpected authentication method will not crash the viewer.
## Before starting the viewer, replace the block controlling the Socks5AuthType in settings.xml with another with a fake value. The following block should work.
<xml>
<key>Socks5AuthType</key>
<map>
<key>Comment</key>
<string>Selected Auth mechanism for Socks5</string>
<key>Persist</key>
<integer>1</integer>
<key>Type</key>
<string>String</string>
<key>Value</key>
<string>FakeAuth</string>
</map>
</xml>
## Start the viewer, but do not log in.
## '''Verify''' that the viewer doesn't crash.
## '''Verify''' that in the settings proxy floater, that authentication is disabled.
## Close the viewer.
## '''Verify''' that Secondlife.log contains the following warning:
"Invalid SOCKS 5 authentication type."

== Proxy Enabled, other HTTP through Web Proxy ==
# Follow the instructions above to enable the proxy and send HTTP traffic through the web proxy.
# This should be run with the firewall fully enabled to ensure the only traffic is being sent through the proxy.
# '''Verify'' that you are able to successfully log into Second Life.

=== Viewer Initialization ===
# '''HTTP Tables Loading''' Verify that the viewer is able to fetch the GPU table and feature table via the proxy.
## The proxy should be enabled before starting this test.
## Close the viewer.
## Start a packet capture on the proxy host that captures on all interfaces. Note: Even if you are unable to use packet filtering software, complete the test and verify that the error strings below are not in the log file.
## Start the viewer but do not log in.
## Inspect the capture for an HTTP request for an HTTP GET for a file of the form gpu_table.X.Y.Z.txt and for featuretable.X.Y.Z.txt.
## '''Verify''' that there was a request originating from the test machine for each of these files, and a subsequent request from the proxy host for the same files. It is normal for each of these requests to receive a 404 response.
## Close the viewer.
## Inspect the Secondlife.log file.
## '''Verify''' that there are no logs matching the following in Secondlife.log.
2011-08-18T21:42:07Z WARNING: LLURLRequest::process_impl: URLRequest Error: 56, Failure when receiving data from the peer, http://viewer-settings.secondlife.com/featuretable_xp.3.0.1.238013.txt
2011-08-18T21:42:07Z INFO: LLPumpIO::processChain: Pump generated pipe err: 'STATUS_ERROR'
2011-08-18T21:42:07Z WARNING: LLURLRequest::process_impl: URLRequest Error: 56, Failure when receiving data from the peer, http://viewer-settings.secondlife.com/gpu_table.3.0.1.238013.txt
2011-08-18T21:42:07Z INFO: LLPumpIO::processChain: Pump generated pipe err: 'STATUS_ERROR'
# '''Login Screen Renders Correctly''' The logon screen should be able to load content from the web using the configured proxy.
## Start the viewer, but do not log in.
##'''Verify''' that the contents of the login screen are displayed.

=== Avatar Navigation and Movement ===
# '''Walking'''
## '''Verify''' that your avatar can move around the world.
# '''Sitting'''
## '''Verify''' that your avatar can sit on objects.
# '''Flying'''
## '''Verify''' that you can fly around the region.
# '''World Map'''
## Open the World Map Floater (World->World Map).
## '''Verify''' that map tiles load and display the layout of the surrounding regions.
## '''Verify''' that green dots representing avatars are displayed.
## Close the World Map.
# '''Minimap'''
## Open the Mini-Map Floater (World->Mini-Map).
## '''Verify''' that map tiles are displayed.
# '''Region Crossing'''
## Fly or walk across a region boundary.
## '''Verify''' that you successfully arrive in the other region.
# '''Intra-region teleport'''
## Teleport by double clicking in the World Map floater, within the current region.
## '''Verify''' that you arrive in the place you clicked.
# '''Inter-region teleport'''
## Teleport by double clicking in the World Map floater, somewhere other than the current region.
## '''Verify''' that you arrive in the new region.

=== Avatar Communication ===
# '''Local Chat'''
## Try sending messages to others avatars standing nearby.
## '''Verify''' that the other people receive your messages and that you can receive messages from them.
# '''Group Chat'''
## Try sending messages to a group chat channel.
## '''Verify''' that you can send messages and receive other messages.
# '''IM'''
## Try sending private IM messages to another avatar.
## '''Verify''' that the other avatar receives your messages, and that you are able to receive their response.
# '''Display Names'''
## '''Verify''' that custom display names are visible for avatars that have them set.

=== Asset Download Tests ===
# Before starting this test, clear your viewer cache and relog.
# '''Texture'''
## '''Verify''' that textures load onto surfaces in your view.
# '''Sounds'''
## Locate the Button_click_down asset in your inventory. Double click the sound to play it.
## '''Verify''' that the sound plays.
# '''Notecard'''
## Locate the Community Standards notecard in the Library of your inventory.
## '''Verify''' that the notecard loads and is readable.
# '''Gestures'''
## Select a gesture from the "Gesture" menu at the bottom of the window.
## '''Verify''' that the gesture plays.
# '''Mesh'''
## Travel to a region with mesh assets available.
## '''Verify''' that the mesh assets rez and are visible.
# '''Legacy Fetch Methods'''
## Enable the Develop menu if you haven't already. (Me->Preferences->Advanced->Show Developer Menu)
## Disable HTTP Inventory and HTTP Textures in the Develop menu.
## Clear the viewer cache.
## Log back into Second Life.
## '''Verify''' that textures load onto surfaces in your view.
## '''Verify''' that your inventory loads.

=== Asset Creation Tests ===
# Move to a region where you have permission to build.
# '''Texture'''
## Upload a test image using the upload tool (Build->Upload->Image).
## When the upload is complete, apply that texture to an object.
## '''Verify''' that the image uploaded successfully.
# '''Sound'''
## Upload a test sound using the upload tool (Build->Upload->Sound)
## When the upload is complete, double click the sound in your inventory to play it back.
## '''Verify''' that the sound plays.
# '''Notecard'''
## In the inventory sidebar, click the "plus sign" (+) button at the bottom of the list of assets.
## In the menu that appears, select "New Notecard".
## Add some text in the body of the notecard and click save.
## Close the notecard
## Reopen the notecard from your inventory.
## '''Verify''' that the notecard text loads.
# '''Mesh'''
## Move to a mesh-enabled region.
## Select Build->Upload->Model to start the mesh upload process.
## In the file selection dialog, select the mesh object you prepared while setting up. The example file is named duck.dae.
## Select "Calculate weights & fee" at the bottom of the Upload Model dialog.
## After the upload fee has been calculated, select the "Upload" button.
## '''Verify''' that the mesh object is added to your inventory.
## Drag the mesh object out of your inventory onto the ground to rez it.
## '''Verify''' that the mesh object is rezzed.
# '''Object Creation'''
## Create a simple object using the build tools.
## '''Verify''' that the object is created
## '''Verify''' that you can take a copy of the created object into your inventory.
# '''Scripting'''
## Right click the object you created in the previous test and select edit.
## Select the content tab of the build floater.
## Click the New Script button.
## Double click the new script to edit.
## Edit the string "Hello, Avatar!" to be "Hi, Avatar!"
## Click save
## '''Verify''' that the script compiles.
## '''Verify''' that the object has sent the message "Hi, Avatar!".

=== Integrated Web Browser ===
# '''Browsing Test''' The integrated webkit browser should be able to browse while accessing the internet through a proxy.
## Enable the built-in browser. (Me->Preferences->Setup->"Use built-in browser", under "Web:").
## Enter a full url, like http://secondlife.com into text chat and send.
## Click the link in the text chat window.
## '''Verify''' that the built-in browser is able to access web content.

=== Media on a Prim ===
# '''Web Media'''
## '''Verify''' that web media is visible.
# '''Video Media'''
## '''Verify''' that video media is visible.

== Proxy Enabled, other HTTP through SOCKS 5 Proxy ==
# '''Repeat Connectivity Tests''' Verify that sending other HTTP traffic through the SOCKS 5 proxy works correctly.
## Configure the viewer as described in the '''Enable proxy connection with HTTP traffic sent through SOCKS 5 proxy.''' section above.
## '''Verify'' that you are able to successfully log into Second Life.
## Rerun the following list of test cases, which are described in the section above.
### Viewer Initialization
### Avatar Navigation and Movement
### Avatar Communication
### Asset Download Tests
### Asset Upload Tests
### Integrated Web Browser
### Media On a Prim
## '''Verify''' that all tests pass.

== No Proxy Enabled ==
# '''Repeat Connectivity Tests''' Verify that users that are not using the proxy will not be negatively impacted by the change.
## Either test on another computer that is not firewalled, or relax the firewall restrictions on the testing network. If using the reference gateway configuration, run the ''nat_forward_all.sh'' script to allow traffic through without going through a proxy.
## Disable the proxy as described above.
## Rerun the following list of test cases, which are described in the section above.
### Viewer Initialization
### Avatar Navigation and Movement
### Avatar Communication
### Asset Download Tests
### Asset Upload Tests
### Integrated Web Browser
### Media On a Prim
## '''Verify''' that all tests pass.
## '''Verify''' that overall viewer performance is approximately the same as usual for the machine you are testing on.
## Re-enable the firewall if you disabled it before further testing.

== SOCKS 5 with Username/Password Authentication ==
# '''Successful Login with SOCKS Authentication''' Test that the viewer can connect when the SOCKS 5 host requires a password.
## Enable both proxies, with "other" traffic going through SOCKS 5.
## Also in the proxy settings floater, select Username/Password as the SOCKS Authentication method.
## Enter your SOCKS 5 username and password in the appropriate fields. If you followed the reference gateway instructions, your linux username and password should work for the socks credentials.
## Select OK.
## Try to log in to Second Life.
## '''Verify''' that login is successful.
## Leave authentication enabled for the next test.
## Optional: The previous set of connectivity tests could be run in this mode as well to verify that the Username/Password authentication method works as well. This is a lower priority than the other three modes because this configuration is behaviorally very similar to the no authentication test, and should either connect or not connect.
# '''SOCKS 5 Password Security''' The SOCKS 5 password should not be stored in cleartext.
## Leave SOCKS 5 authentication enabled in the viewer from the previous test.
## Close all running instances of the viewer.
## Navigate to the user's Second Life settings directory.
## Search, using grep or ctrl-f in notepad depending on the platform, for the username and password you used to connect to the SOCKS 5 server in the previous step in the settings.xml that corresponds to the viewer version you are testing with (settings.xml if using a release version, settings_development.xml if using a development build, etc).
## '''Verify''' that the username and password do not appear in the settings files.
## Start the viewer and disable authentication.

----


= Pass/Fail Criteria =
# '''Passes''' if
## No unexpected behaviors are observed
# '''Fails''' if
## Deviation from expected behavior is observed
## A bug is detected that was not accounted for by this test plan
## Performance degradation is observed when the proxy is disabled.
# '''Known Issues'''
## SLVoice does not support proxies, therefore voice is not expected to work when running the viewer behind a strict firewall that blocks the ports used for voice communication. If voice is enabled, an error message will appear when the viewer fails to connect to the voice server.

= Tear Down =
* Disable all proxies in the viewer configuration.
* Disable the built-in browser.

User:Log Linden/Socks5Viewer/TestPlan

2011-08-18T15:13:23Z

Log Linden: Added configuration validation.

[[Category:Test Scripts]]
{| cellspacing="0" cellpadding="0" style="clear: {{{clear|right}}}; margin-bottom: .5em; float: right; padding: .5em 0 .8em 1.4em; background: none; width: {{{width|{{{1|auto}}}}}};" {{#if:{{{limit|}}}|class="toclimit-{{{limit}}}"}}
| __TOC__
|}
= Scope =
* This test is to verify that newly added proxy support in the viewer works as expected.
* The user story that prompted the changes is [https://jira.secondlife.com/browse/STORM-1112 STORM-1112 ].
* This test will only be meaningful if performed in a network environment that does not have access to second life.
* The test also requires a working web proxy host and SOCKS 5 proxy host.
* Estimated running time: 3 hours/platform after securing the appropriate test environment.

= Set-up =
== Environment ==
* Viewer: This test requires a build of the viewer that contains the LLProxy code. Grab the latest for your platform from the link below:
{{ViewerInstallers|{{JiraIssue|STORM-1112|Implement SOCKS 5 proxy}}| Allow the Second Life Viewer to connect through a SOCKS 5 proxy. |task=log_viewer-socks5|repo=https://bitbucket.org/log_linden/viewer_socks5}}
* Server: The test requires testing of mesh upload and download functionality, so access to a region with mesh support is required. Agni or Aditi are each fine. Region crossing will also be tested, so adjacent regions to test in will also be required.
* A restrictive, firewalled network to connect the testing machine to is required to obtain valid test results.
* A working web proxy host and a working SOCKS 5 host are required to complete the test.
* Instructions to set up a reference Ubuntu Linux server that will act as a firewall and proxy gateway [[User:Log_Linden/Socks5Viewer/TestPlan/ProxyGateway | are available]].
* While 3rd party testers are welcome to set up a duplicate of our reference gateway server, we are also interested in results you might get in your organization's specific network setup, rather than using our reference setup. Since you might not be allowed to reconfigure your organization's firewall or proxy host, feel free to only test in the proxy configuration your organization supports and report on results you observe.

== Other ==
* Second Life account that is able to upload mesh assets on the grid being tested.
* Your avatar should be a member of a group and be allowed to send messages in that group for testing.
* Part of the test is making sure land parcel media is functional. Find somewhere in world that has botha
* Sandbox, or other area where building is allowed.
* Enable advanced mode. The proxy options are not available in basic mode.
* Have a test image file, sound file, and collada model available to test upload functionality. A sample collada model is available from the [collada.org website | https://collada.org/owl/download.php?sess=0&parent=126&expand=1&order=name&curview=0&binary=1&id=698/ ].

= Common Procedures =
Refer to this section when asked to do one of the following in a test step.
# '''Enable proxy connection with HTTP traffic sent through web proxy.'''
## Change these settings before logging into Second Life.
## Open the Proxy settings floater. Me->Preferences->Setup->"Adjust Proxy Settings"
## Check "Use HTTP Proxy for Web pages" and enter the address and port number.
## Check "Use SOCKS 5 Proxy for UDP traffic" and enter the address and port number.
## Under other HTTP traffic proxy, select "Use HTTP Proxy".
## Click OK.

# '''Enable proxy connection with HTTP traffic sent through SOCKS 5 proxy.'''
## Change these settings before logging into Second Life.
## Open the Proxy settings floater. Me->Preferences->Setup->"Adjust Proxy Settings"
## Check "Use HTTP Proxy for Web pages" and enter the address and port number.
## Check "Use SOCKS 5 Proxy for UDP traffic" and enter the address and port number.
## Under other HTTP traffic proxy, select "Use SOCKS 5 Proxy".
## Click OK.

# '''Disable all proxies'''
## Change these settings before logging into Second Life.
## Open the Proxy settings floater. Me->Preferences->Setup->"Adjust Proxy Settings"
## Uncheck "Use HTTP Proxy for Web pages".
## Uncheck "Use SOCKS 5 Proxy for UDP traffic".
## Click OK.

# '''Clear Viewer Caches'''
## Click the "Clear Cache" button on the advanced tab of the preferences floater.
## Confirm that you want to clear the cache.
## Restart the Viewer.

= Test Steps =
== Configuration Consistency Checks ==
# '''Expected Defaults''' Check the default configuration.
## Install a version of the viewer that supports LLProxy communication.
## Start the viewer that was installed, but do not log in.
## Navigate to the proxy control floater (Me->Preferences->Setup->Adjust proxy Settings.
## Inspect the settings.
## '''Verify''' that both proxies are disabled.
## Leave this floater open for the next test.
# '''Invalid HTTP Proxy Configuration Error-Handling'''
## Enable both proxies, type in valid information for both proxies.
## Change the "Other HTTP traffic proxy" option to "Use SOCKS 5 proxy".
## Quit the viewer.
## Edit the settings.xml file that corresponds to the channel of the viewer you are using to test with (e.g. settings_developer.xml, settings.xml, settings_beta.xml, etc.).
## Change the value of Socks5ProxyEnabled to be "0". The block should look like the following.
<xml>
<key>Socks5ProxyEnabled</key>
<map>
<key>Comment</key>
<string>Use Socks5 Proxy</string>
<key>Persist</key>
<integer>1</integer>
<key>Type</key>
<string>Boolean</string>
<key>Value</key>
<integer>0</integer>
</map>
</xml>
## Restart the viewer.
## '''Verify''' that the viewer doesn't crash
## Open the proxy preferences floater.
## '''Verify''' that the "Other HTTP traffic" proxy option is now set to '''Do not proxy''.'
## Quit the viewer.
## '''Verify''' that Secondlife.log contains the following warning:
"Invalid other HTTP proxy configuration."
# '''Invalid authentication configuration error-handling.''' Test that an unexpected authentication method will not crash the viewer.
## Before starting the viewer, replace the block controlling the Socks5AuthType in settings.xml with another with a fake value. The following block should work.
<xml>
<key>Socks5AuthType</key>
<map>
<key>Comment</key>
<string>Selected Auth mechanism for Socks5</string>
<key>Persist</key>
<integer>1</integer>
<key>Type</key>
<string>String</string>
<key>Value</key>
<string>FakeAuth</string>
</map>
</xml>
## Start the viewer, but do not log in.
## '''Verify''' that the viewer doesn't crash.
## '''Verify''' that in the settings proxy floater, that authentication is disabled.
## Close the viewer.
## '''Verify''' that Secondlife.log contains the following warning:
"Invalid SOCKS 5 authentication type."

== Proxy Enabled, other HTTP through Web Proxy ==
# Follow the instructions above to enable the proxy and send HTTP traffic through the web proxy.

=== Viewer Initialization ===
# '''HTTP Tables Loading''' Verify that the GPU table and feature table are able to be fetched by the proxy.
## Browse to the install directory of the viewer.
# '''Login Screen Renders Correctly
=== Avatar Navigation and Movement ===
# '''Walking'''goo
## '''Verify''' that your avatar can move around the world.
# '''Sitting'''
## '''Verify''' that your avatar can sit on objects.
# '''Flying'''
## '''Verify''' that you can fly around the region.
# '''World Map'''
## Open the World Map Floater (World->World Map).
## '''Verify''' that map tiles load and display the layout of the surrounding regions.
## '''Verify''' that green dots representing avatars are displayed.
## Close the World Map.
# '''Minimap'''
## Open the Mini-Map Floater (World->Mini-Map).
## '''Verify''' that map tiles are displayed.
# '''Region Crossing'''
## Fly or walk across a region boundary.
## '''Verify''' that you successfully arrive in the other region.
# '''Intra-region teleport'''
## Teleport by double clicking in the World Map floater, within the current region.
## '''Verify''' that you arrive in the place you clicked.
# '''Inter-region teleport'''
## Teleport by double clicking in the World Map floater, somewhere other than the current region.
## '''Verify''' that you arrive in the new region.

=== Avatar Communication ===
# '''Local Chat'''
## Try sending messages to others avatars standing nearby.
## '''Verify''' that the other people receive your messages and that you can receive messages from them.
# '''Group Chat'''
## Try sending messages to a group chat channel.
## '''Verify''' that you can send messages and receive other messages.
# '''IM'''
## Try sending private IM messages to another avatar.
## '''Verify''' that the other avatar receives your messages, and that you are able to receive their response.
# '''Display Names'''
## '''Verify''' that custom display names are visible for avatars that have them set.
=== Asset Download Tests ===
# Before starting this test, clear your viewer cache and relog.
# '''Texture'''
## '''Verify''' that textures load onto surfaces in your view.
# '''Sounds'''
## Locate the Button_click_down asset in your inventory. Double click the sound to play it.
## '''Verify''' that the sound plays.
# '''Notecard'''
## Locate the Community Standards notecard in the Library of your inventory.
## '''Verify''' that the notecard loads and is readable.
# '''Gestures'''
## Select a gesture from the "Gesture" menu at the bottom of the window.
## '''Verify''' that the gesture plays.
# '''Mesh'''
## Travel to a region with mesh assets available.
## '''Verify''' that the mesh assets rez and are visible.

# '''Legacy Fetch Methods'''
## Enable the Develop menu if you haven't already. (Me->Preferences->Advanced->Show Developer Menu)
## Disable HTTP Inventory and HTTP Textures in the Develop menu.
## Clear the viewer cache.
## Log back into Second Life.
## '''Verify''' that textures load onto surfaces in your view.
## '''Verify''' that your inventory loads.

=== Asset Creation Tests ===
# Move to a region where you have permission to build.
# '''Texture'''
## Upload a test image using the upload tool (Build->Upload->Image).
## When the upload is complete, apply that texture to an object.
## '''Verify''' that the image uploaded successfully.
# '''Sound'''
## Upload a test sound using the upload tool (Build->Upload->Sound)
## When the upload is complete, double click the sound in your inventory to play it back.
## '''Verify''' that the sound plays.
# '''Notecard'''
## In the inventory sidebar, click the "plus sign" (+) button at the bottom of the list of assets.
## In the menu that appears, select "New Notecard".
## Add some text in the body of the notecard and click save.
## Close the notecard
## Reopen the notecard from your inventory.
## '''Verify''' that the notecard text loads.
# '''Mesh'''
## Move to a mesh-enabled region.
## Select Build->Upload->Model to start the mesh upload process.
## In the file selection dialog, select the mesh object you prepared while setting up. The example file is named duck.dae.
## Select "Calculate weights & fee" at the bottom of the Upload Model dialog.
## After the upload fee has been calculated, select the "Upload" button.
## '''Verify''' that the mesh object is added to your inventory.
## Drag the mesh object out of your inventory onto the ground to rez it.
## '''Verify''' that the mesh object is rezzed.
# '''Object Creation'''
## Create a simple object using the build tools.
## '''Verify''' that the object is created
## '''Verify''' that you can take a copy of the created object into your inventory.
# '''Scripting'''
## Right click the object you created in the previous test and select edit.
## Select the content tab of the build floater.
## Click the New Script button.
## Double click the new script to edit.
## Edit the string "Hello, Avatar!" to be "Hi, Avatar!"
## Click save
## '''Verify''' that the script compiles.
## '''Verify''' that the object has sent the message "Hi, Avatar!".

=== Integrated Web Browser ===
# '''Browsing Test''' The integrated webkit browser should be able to browse while accessing the internet through a proxy.
## Enable the built-in browser. (Me->Preferences->Setup->"Use built-in browser", under "Web:".
## Enter a full url, like http://secondlife.com into text chat and send.
## Click the link in the text chat window.
## '''Verify''' that the built-in browser is able to access web content.

=== Media on a Prim ===
# '''Web Media'''
## '''Verify''' that web media is visible.
# '''Video Media'''
## '''Verify''' that video media is visible.

== Proxy Enabled, other HTTP through SOCKS 5 Proxy ==
# '''Repeat Connectivity Tests''' Verify that sending other HTTP traffic through the SOCKS 5 proxy works correctly.
## Rerun the following list of test cases, which are described in the section above.
### Viewer Initialization
### Avatar Navigation and Movement
### Avatar Communication
### Asset Download Tests
### Asset Upload Tests
### Integrated Web Browser
### Media On a Prim
## '''Verify''' that all tests pass.

== No Proxy Enabled ==
# '''Repeat Connectivity Tests''' Verify that users that are not using the proxy will not be negatively impacted by the change.
## Either test on another computer that is not firewalled, or relax the firewall restrictions on the testing network. If using the reference gateway configuration, run the ''nat_forward_all.sh'' script to allow traffic through without going through a proxy.
## Disable the proxy as described above.
## Rerun the following list of test cases, which are described in the section above.
### Viewer Initialization
### Avatar Navigation and Movement
### Avatar Communication
### Asset Download Tests
### Asset Upload Tests
### Integrated Web Browser
### Media On a Prim
## '''Verify''' that all tests pass.
## '''Verify''' that overall viewer performance is approximately the same as usual for the machine you are testing on.
## Re-enable the firewall if you disabled it before further testing.

== SOCKS 5 with Username/Password Authentication ==
# '''Successful Login with SOCKS Authentication''' Test that the viewer can connect when the SOCKS 5 host requires a password.
## Enable both proxies, with "other" traffic going through SOCKS 5.
## Also in the proxy settings floater, select Username/Password as the SOCKS Authentication method.
## Enter your SOCKS 5 username and password in the appropriate fields. If you followed the reference gateway instructions, your linux username and password should work for the socks credentials.
## Select OK.
## Try to log in to Second Life.
## '''Verify''' that login is successful.
## Leave authentication enabled for the next test.
## Optional: The previous set of connectivity tests could be run in this mode as well to verify that the Username/Password authentication method works as well. This is a lower priority than the other three modes because this configuration is behaviorally very similar to the no authentication test, and should either connect or not connect.
# '''SOCKS 5 Password Security''' The SOCKS 5 password should not be stored in cleartext.
## Leave SOCKS 5 authentication enabled in the viewer from the previous test.
## Close all running instances of the viewer.
## Navigate to the user's Second Life settings directory.
## Search, using grep or ctrl-f in notepad depending on the platform, for the username and password you used to connect to the SOCKS 5 server in the previous step in the settings.xml that corresponds to the viewer version you are testing with (settings.xml if using a release version, settings_development.xml if using a development build, etc).
## '''Verify''' that the username and password do not appear in the settings files.
## Start the viewer and disable authentication.

----


= Pass/Fail Criteria =
# '''Passes''' if
## No unexpected behaviors are observed
# '''Fails''' if
## Deviation from expected behavior is observed
## A bug is detected that was not accounted for by this test plan
## Performance degradation is observed when the proxy is disabled.
# '''Known Issues'''
## SLVoice does not support proxies, therefore voice is not expected to work when running the viewer behind a strict firewall that blocks the ports used for voice communication. If voice is enabled, an error message will appear when the viewer fails to connect to the voice server.

= Tear Down =
* Disable all proxies in the viewer configuration.

User:Log Linden/Socks5Viewer/TestPlan/ProxyGateway

2011-08-16T19:31:21Z

Log Linden: /* Configure the HTTP proxy */ Removed a restriction on the which ports squid will allow a client to establish a ssl connection with.

= Introduction =
These instructions will help you set up a simple Ubuntu gateway machine that will allow you to control access to the outside network for computers that are operating behind the gateway. This setup was created for testing the SOCKS 5 proxy. With some modification, the same setup could be used for testing various other network conditions, including throttling the connection speed down to something closer to residential DSL speeds. The instructions are intended for someone with a reasonable familiarity with Ubuntu Linux and will only discuss the customisations needed to set up the gateway.

= Requirements =
== Hardware ==
* A standard off-the-shelf PC with two Ethernet NICs
* 1 Ethernet switch for the "internal" network
* Network cables
* Other computers to actually test the viewer on.

== Software ==
* Ubuntu Linux 11.04 (Natty) [http://www.ubuntu.com/download/ubuntu/download install media] (Other flavors of Ubuntu, including Ubuntu server should work with these instructions as well.)

= Instructions =
== Connect network hardware ==
* Connect one network card to the outside network.
* Connect the other network card to the internal ethernet switch.
* Connect testing computers to the internal network switch.
[[File:Socks_test_setup.2.png|border|600px|SOCKS Testing Network Setup]]

== Install Ubuntu and Packages ==
* Install Ubuntu on the gateway machine. Consult the official Ubuntu install [https://help.ubuntu.com/community/GraphicalInstall instructions] for more information.
* Reboot into the installed system.
* Update the packages on the system.
<bash>
sudo apt-get update
sudo apt-get upgrade
</bash>
* Install some additional useful packages that we will need.
<bash> sudo apt-get install dnsmasq dante-server openssh </bash>
== Configure Network Interfaces ==
* IMPORTANT NOTE: For the purpose of this document, eth0 is the device that is connecting to the outside network, and eth1 is connecting to the internal network. Verify which is which on your setup.
<bash>ifconfig</bash>
Chances are, only one of the ethX devices will have been assigned an IP address by your network, this is the one connected to the external network. If this is not eth0 you need to either switch the network cables connected to the computer or remember to swap the interface names everywhere in the rest of this document. We are going to be assigning eth1 with a static IP address, which can cause problems if it conflicts with the rest of your network.
* Edit, with sudo, '/etc/network/interfaces' and replace its contents with the following
<bash>
auto lo eth0 eth1

iface lo inet loopback

# External network
iface eth0 inet dhcp

# Internal network
iface eth1 inet static
address 192.168.1.1
network 192.168.1.0
netmask 255.255.255.0
broadcast 192.168.1.255
</bash>
* This configuration makes eth0 continue to get its configuration through DHCP, and statically configures eth1. Listing both interfaces on the auto line will mean that they will automatically connect on startup.
* Because we are setting up the interfaces in this config file, we should probably prevent networkmanager from trying to do it as well.
<bash> sudo update-rc.d NetworkManager remove</bash>
* Restart the network
<bash>
sudo /etc/init.d/networking stop
sudo /etc/init.d/networking start
</bash>
* Verify the network configuration by looking for the correct IP addresses for eth0 and eth1.
<bash> ifconfig</bash>

== Set up DNS and DHCP ==
* dnsmasq is a lightweight combination DNS/DHCP server. For the anticipated number of clients for this network, it should be sufficient.
* Warning: Again, it is important to get the network interfaces correct for this. Running a rogue DHCP server on the wrong interface could cause major network problems. eth1 should be the '''internal''' network card.
* Replace /etc/dnsmasq.conf with the following:
<bash>
interface=eth1

dhcp-range=192.168.1.50,192.168.1.150,12h
dhcp-authoritative
dhcp-script=/bin/echo
</bash>
* Restart dnsmasq
<bash> sudo /etc/init.d/dnsmasq restart </bash>

== Set up the Firewall ==
* Save the following two scripts to ~/scripts
=== nat_forward_all.sh ===
<bash>
echo -e "\n\nLoading simple rc.firewall-iptables version $FWVER..\n"
DEPMOD=/sbin/depmod
MODPROBE=/sbin/modprobe

EXTIF="eth0"
INTIF="eth1"
echo " External Interface: $EXTIF"
echo " Internal Interface: $INTIF"

#======================================================================
#== No editing beyond this line is required for initial MASQ testing ==
echo -en " loading modules: "
echo " - Verifying that all kernel modules are ok"
$DEPMOD -a
echo "----------------------------------------------------------------------"
echo -en "ip_tables, "
$MODPROBE ip_tables
echo -en "nf_conntrack, "
$MODPROBE nf_conntrack
echo -en "nf_conntrack_ftp, "
$MODPROBE nf_conntrack_ftp
echo -en "nf_conntrack_irc, "
$MODPROBE nf_conntrack_irc
echo -en "iptable_nat, "
$MODPROBE iptable_nat
echo -en "nf_nat_ftp, "
$MODPROBE nf_nat_ftp
echo "----------------------------------------------------------------------"
echo -e " Done loading modules.\n"
echo " Enabling forwarding.."
echo "1" > /proc/sys/net/ipv4/ip_forward
echo " Enabling DynamicAddr.."
echo "1" > /proc/sys/net/ipv4/ip_dynaddr
echo " Clearing any existing rules and setting default policy.."

iptables-restore <<-EOF
*nat
-A POSTROUTING -o "$EXTIF" -j MASQUERADE
COMMIT
*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A FORWARD -i "$EXTIF" -o "$INTIF" -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -i "$INTIF" -o "$EXTIF" -j ACCEPT
-A FORWARD -j LOG
COMMIT
EOF

echo -e "\nrc.firewall-iptables v$FWVER done.\n"
</bash>
=== nat_block_all.sh ===
<bash>
echo -e "\n\nLoading simple rc.firewall-iptables version $FWVER..\n"
DEPMOD=/sbin/depmod
MODPROBE=/sbin/modprobe

EXTIF="eth0"
INTIF="eth1"
echo " External Interface: $EXTIF"
echo " Internal Interface: $INTIF"

#======================================================================
#== No editing beyond this line is required for initial MASQ testing ==
echo -en " loading modules: "
echo " - Verifying that all kernel modules are ok"
$DEPMOD -a
echo "----------------------------------------------------------------------"
echo -en "ip_tables, "
$MODPROBE ip_tables
echo -en "nf_conntrack, "
$MODPROBE nf_conntrack
echo -en "nf_conntrack_ftp, "
$MODPROBE nf_conntrack_ftp
echo -en "iptable_nat, "
$MODPROBE iptable_nat
echo -en "nf_nat_ftp, "
$MODPROBE nf_nat_ftp
echo "----------------------------------------------------------------------"
echo -e " Done loading modules.\n"
echo " Enabling forwarding.."
echo "1" > /proc/sys/net/ipv4/ip_forward
echo " Enabling DynamicAddr.."
echo "1" > /proc/sys/net/ipv4/ip_dynaddr
echo " Clearing any existing rules and setting default policy.."

iptables-restore <<-EOF
*nat
-A POSTROUTING -o "$EXTIF" -j MASQUERADE
COMMIT
*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A FORWARD -i "$INTIF" -j LOG
-A FORWARD -i "$INTIF" -j REJECT
COMMIT
EOF

echo -e "\nrc.firewall-iptables v$FWVER done.\n"
</bash>
* Make both scripts executable
<bash>
chmod a+x ~/scripts/nat_block_all.sh
chmod a+x ~/scripts/nat_forward_all.sh
</bash>
* Test the wide-open script. Inspect the output for errors indicating something is wrong.
<bash>
sudo ~/scripts/nat_forward_all.sh
</bash>
* If the previous command was successful and you got dns and dhcp configured before, you should be able to connect through your gateway on computers on the internal network.
* Test this now, by connecting a test computer to the network if you haven't already. Try browsing the web on one of the test machines as a quick test. Use '''ipconfig /all''' or '''ifconfig''' to see how the test computer is being configured. Expected values are below:
{| class="lltable" border="1"
|+ '''Test Machine Network Parameters'''

|--
!Parameter
!Expected Value

|--
| IP Address
| 192.168.1.50-192.168.1.150

|--
| Subnet Mask
| 255.255.255.0

|--
| Default Gateway
| 192.168.1.1

|--
| Nameserver (DNS Server)
| 192.168.1.1

|}

* If everything seems to be working correctly, make the wide-open config run during system startup.
<bash>
sudo cp nat_forward_all.sh /etc/init.d/nat.sh
sudo ln -s /etc/init.d/nat.sh /etc/rc2.d/S95masquradescript
</bash>

== Set up the SOCKS 5 proxy==
* Replace /etc/danted.conf with the following.
<pre>
logoutput: /var/log/dante.log

internal: eth1 port = 1080

external: eth0

method: username none
# Accept either username auth or no auth. If using username auth, use the same username and password that are used to sign on to this machine.

#user.privileged: proxy
user.notprivileged: nobody

### "client-rules" ###

client pass {
from: 192.168.1.0/24 port 1-65535 to: 0.0.0.0/0
}

client block {
from: 0.0.0.0/0 to: 0.0.0.0/0
log: connect error
}

### "socks-rules" ###
# Block connections to loopback interfaces
block {
from: 0.0.0.0/0 to: 127.0.0.0/8
log: connect error
}

# Allow udp reply packets from outside
pass {
from: 0.0.0.0/0 to: 192.168.1.0/24
command: udpreply
}

# Allow the internal network to connect to everything outside
pass {
from: 192.168.1.0/24 to: 0.0.0.0/0
protocol: tcp udp
}

# Block anything else
block {
from: 0.0.0.0/0 to: 0.0.0.0/0
log: connect error
}

</pre>
* Start the proxy server
<bash> sudo /etc/init.d/danted restart </bash>
* If you get a "Failed to open libc.so..." error message when starting the proxy server, this is caused by a [https://bugs.launchpad.net/ubuntu/+source/dante/+bug/767085 mistake] in the dante-server debian package. To work around this, create a simlink to the correct libc.so and try to start danted again.
<bash> sudo ln -sf /lib/i386-linux-gnu/libc-2.13.so /lib/i386-linux-gnu/libc.so </bash>
* Test connecting through the proxy by configuring the web browser on one of the test machines connected through the gateway to use the proxy.
* Restrict outgoing traffic through the gateway by enabling the more restrictive iptables configuration.
<bash> sudo ~/scripts/nat_block_all.sh </bash>
* In the proxy options section of the browser, supply 192.168.1.1 as the SOCKS server and 1080 as the port.
* Attempt to browse to an internet website. If you can browse as usual, the proxy is working correctly.
* Disable the proxy in the browser.

== Set up the HTTP (Web) proxy ==
=== Configure the HTTP proxy ===
* Edit /etc/squid/squid.conf. We will be editing the existing file instead of replacing it. We need to open up some ports, enable SSL communication via the CONNECT method, and disable caching.
* A patch that will give us the access we need:
<diff>
--- squid.conf.original 2011-07-11 13:58:12.640564821 -0400
+++ squid.conf 2011-08-16 15:22:55.420862811 -0400
@@ -606,8 +606,6 @@
# Example rule allowing access from your local networks.
# Adapt to list your (internal) IP networks from where browsing
# should be allowed
-acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
-acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
#
acl SSL_ports port 443 # https
@@ -628,6 +626,8 @@
acl Safe_ports port 901 # SWAT
acl purge method PURGE
acl CONNECT method CONNECT
+# Enable SSL via CONNECT
+acl SSL method CONNECT

# TAG: http_access
# Allowing or Denying access based on defined access lists
@@ -661,7 +661,8 @@
# Deny requests to unknown ports
http_access deny !Safe_ports
# Deny CONNECT to other than SSL ports
-http_access deny CONNECT !SSL_ports
+## Removed to allow connection to caps router on simhosts.
+#http_access deny CONNECT !SSL_ports
#
# We strongly recommend the following be uncommented to protect innocent
# web applications running on the proxy server who think the only
@@ -675,6 +676,8 @@
# from where browsing should be allowed
#http_access allow localnet
http_access allow localhost
+http_access allow localnet
+

# And finally deny all other access to this proxy
http_access deny all
@@ -1111,8 +1114,9 @@
# visible on the internal address.
#
# Squid normally listens to port 3128
-http_port 3128
+http_port 192.168.1.1:3128

+cache deny all
# TAG: https_port
# Note: This option is only available if Squid is rebuilt with the
# --enable-ssl option
@@ -3939,7 +3943,7 @@
# "0". May be overridden with -u on the command line.
#
#Default:
-# icp_port 3130
+icp_port 0

# TAG: htcp_port
# The port number where Squid sends and receives HTCP queries to

</diff>

* To apply the patch, save it to a file named squid.diff in your home directory and run the following command:
<bash>
sudo patch /etc/squid/squid.conf ~/squid.diff
</bash>

* If you would rather edit by hand, a sequence of instructions to do the above are listed below.1
* Look for the following line:
http_port 3128
* Replace with the following:
http_port 192.168.1.1:3128
cache deny all
* Look for the following lines:
acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network

* Replace with
acl localnet src 192.168.1.0/8 # RFC1918 possible internal network

* Look for the following line:
acl CONNECT method CONNECT
* Append two lines after to make it look like this:
acl CONNECT method CONNECT
# Enable SSL via CONNECT
acl SSL method CONNECT

* Comment out the following line:
http_access deny CONNECT !SSL_ports
* It should look like this:
#http_access deny CONNECT !SSL_ports

* Look for the following line:
http_access allow localhost
* Append another line after it so that it now looks like this:
http_access allow localhost
http_access allow localnet

* Now that the configuration file is correct, we need to restart the squid proxy:
<bash>
sudo stop squid
sudo start squid
</bash>
* Examine syslog for any errors related to squid.
<bash>
sudo tail /var/log/syslog
</bash>

=== Test the HTTP Proxy ===
* Restrict outgoing traffic through the gateway by enabling the more restrictive iptables configuration.
<bash> sudo ~/scripts/nat_block_all.sh </bash>
* In the proxy options section of the browser on the test machine, supply 192.168.1.1 as the HTTP and HTTPS proxy server with 3128 as the port in both cases.
* Remove any SOCKS proxy configuration in the browser.
* Attempt to browse to an internet website. Also try browsing to an https:// website such as [https://codereview.secondlife.com https://codereview.secondlife.com]. If you can browse as usual, the proxy is working correctly.
* Disable the proxy in the browser.

== Cleanup ==
* Reboot the machine, using the graphical menus to reboot or the following command. Verify that everything still works as before.
<bash> sudo shutdown -r now </bash>
* Note that we left the unrestricted firewall configuration as the default. When the gateway is rebooted, you will need to rerun '''~/scripts/nat_blocked_all.sh''' to restrict connections again. If you would like that to be the default state, copy '''~/scripts/nat_blocked_all.sh''' to '''/etc/init.d/nat.sh'''.

= Useful References =
If you run into difficulties with these instructions, there is more information in the official documentation. I based the configurations in this document mostly from the following sites:
*[https://help.ubuntu.com/community/Router Ubuntu Router Instructions]

User:Log Linden/Socks5Viewer/TestPlan

2011-08-12T17:24:42Z

Log Linden:

[[Category:Test Scripts]]
{| cellspacing="0" cellpadding="0" style="clear: {{{clear|right}}}; margin-bottom: .5em; float: right; padding: .5em 0 .8em 1.4em; background: none; width: {{{width|{{{1|auto}}}}}};" {{#if:{{{limit|}}}|class="toclimit-{{{limit}}}"}}
| __TOC__
|}
= Scope =
* This test is to verify that newly added proxy support in the viewer works as expected.
* The user story that prompted the changes is [https://jira.secondlife.com/browse/STORM-1112 STORM-1112 ].
* This test will only be meaningful if performed in a network environment that does not have access to second life.
* The test also requires a working web proxy host and SOCKS 5 proxy host.
* Estimated running time: 3 hours/platform after securing the appropriate test environment.

= Set-up =
== Environment ==
* Viewer: This test requires a build of the viewer that contains the Proxy code. Grab the latest for your platform from the link below:
{{ViewerInstallers|{{JiraIssue|STORM-1112|Implement SOCKS 5 proxy}}| Allow the Second Life Viewer to connect through a SOCKS 5 proxy. |task=log_viewer-socks5|repo=https://bitbucket.org/log_linden/viewer_socks5}}
* Server: The test requires testing of mesh upload and download functionality, so access to a region with mesh support is required. Agni or Aditi are each fine. Region crossing will also be tested, so adjacent regions to test in will also be required.
* A restrictive, firewalled network to connect the testing machine to is required to obtain valid test results.
* A working web proxy host and a working SOCKS 5 host are required to complete the test.
* Instructions to set up a reference Ubuntu Linux server that will act as a firewall and proxy gateway [[User:Log_Linden/Socks5Viewer/TestPlan/ProxyGateway | are available]].
* While 3rd party testers are welcome to set up a duplicate of our reference gateway server, we are also interested in results you might get in your organization's specific network setup, rather than using our reference setup. Since you might not be allowed to reconfigure your organization's firewall or proxy host, feel free to only test in the proxy configuration your organization supports and report on results you observe.

== Other ==
* Second Life account that is able to upload mesh assets on the grid being tested.
* Your avatar should be a member of a group and be allowed to send messages in that group for testing.
* Part of the test is making sure land parcel media is functional. Find somewhere in world that has botha
* Sandbox, or other area where building is allowed.
* Enable advanced mode. The proxy options are not available in basic mode.
* Have a test image file, sound file, and collada model available to test upload functionality. A sample collada model is available from the [collada.org website | https://collada.org/owl/download.php?sess=0&parent=126&expand=1&order=name&curview=0&binary=1&id=698/ ].

= Common Procedures =
Refer to this section when asked to do one of the following in a test step.
# '''Enable proxy connection with HTTP traffic sent through web proxy.'''
## Change these settings before logging into Second Life.
## Open the Proxy settings floater. Me->Preferences->Setup->"Adjust Proxy Settings"
## Check "Use HTTP Proxy for Web pages" and enter the address and port number.
## Check "Use SOCKS 5 Proxy for UDP traffic" and enter the address and port number.
## Under other HTTP traffic proxy, select "Use HTTP Proxy".
## Click OK.

# '''Enable proxy connection with HTTP traffic sent through SOCKS 5 proxy.'''
## Change these settings before logging into Second Life.
## Open the Proxy settings floater. Me->Preferences->Setup->"Adjust Proxy Settings"
## Check "Use HTTP Proxy for Web pages" and enter the address and port number.
## Check "Use SOCKS 5 Proxy for UDP traffic" and enter the address and port number.
## Under other HTTP traffic proxy, select "Use SOCKS 5 Proxy".
## Click OK.

# '''Disable all proxies'''
## Change these settings before logging into Second Life.
## Open the Proxy settings floater. Me->Preferences->Setup->"Adjust Proxy Settings"
## Uncheck "Use HTTP Proxy for Web pages".
## Uncheck "Use SOCKS 5 Proxy for UDP traffic".
## Click OK.

# '''Clear Viewer Caches'''
## Click the "Clear Cache" button on the advanced tab of the preferences floater.
## Confirm that you want to clear the cache.
## Restart the Viewer.

= Test Steps =
== Configuration Consistency Checks ==
# '''Expected Defaults''' Check the default configuration.
## step 1
## step 2
## '''Verify''' against expected behavior

== Proxy Enabled, other HTTP through Web Proxy ==
# Follow the instructions above to enable the proxy and send HTTP traffic through the web proxy.

=== Viewer Initialization ===
# '''HTTP Tables Loading''' Verify that the GPU table and feature table are able to be fetched by the proxy.
## Browse to the install directory of the viewer.
# '''Login Screen Renders Correctly
=== Avatar Navigation and Movement ===
# '''Walking'''
## '''Verify''' that your avatar can move around the world.
# '''Sitting'''
## '''Verify''' that your avatar can sit on objects.
# '''Flying'''
## '''Verify''' that you can fly around the region.
# '''World Map'''
## Open the World Map Floater (World->World Map).
## '''Verify''' that map tiles load and display the layout of the surrounding regions.
## '''Verify''' that green dots representing avatars are displayed.
## Close the World Map.
# '''Minimap'''
## Open the Mini-Map Floater (World->Mini-Map).
## '''Verify''' that map tiles are displayed.
# '''Region Crossing'''
## Fly or walk across a region boundary.
## '''Verify''' that you successfully arrive in the other region.
# '''Intra-region teleport'''
## Teleport by double clicking in the World Map floater, within the current region.
## '''Verify''' that you arrive in the place you clicked.
# '''Inter-region teleport'''
## Teleport by double clicking in the World Map floater, somewhere other than the current region.
## '''Verify''' that you arrive in the new region.

=== Avatar Communication ===
# '''Local Chat'''
## Try sending messages to others avatars standing nearby.
## '''Verify''' that the other people receive your messages and that you can receive messages from them.
# '''Group Chat'''
## Try sending messages to a group chat channel.
## '''Verify''' that you can send messages and receive other messages.
# '''IM'''
## Try sending private IM messages to another avatar.
## '''Verify''' that the other avatar receives your messages, and that you are able to receive their response.
# '''Display Names'''
## '''Verify''' that custom display names are visible for avatars that have them set.
=== Asset Download Tests ===
# Before starting this test, clear your viewer cache and relog.
# '''Texture'''
## '''Verify''' that textures load onto surfaces in your view.
# '''Sounds'''
## Locate the Button_click_down asset in your inventory. Double click the sound to play it.
## '''Verify''' that the sound plays.
# '''Notecard'''
## Locate the Community Standards notecard in the Library of your inventory.
## '''Verify''' that the notecard loads and is readable.
# '''Gestures'''
## Select a gesture from the "Gesture" menu at the bottom of the window.
## '''Verify''' that the gesture plays.
# '''Mesh'''
## Travel to a region with mesh assets available.
## '''Verify''' that the mesh assets rez and are visible.

# '''Legacy Fetch Methods'''
## Enable the Develop menu if you haven't already. (Me->Preferences->Advanced->Show Developer Menu)
## Disable HTTP Inventory and HTTP Textures in the Develop menu.
## Clear the viewer cache.
## Log back into Second Life.
## '''Verify''' that textures load onto surfaces in your view.
## '''Verify''' that your inventory loads.

=== Asset Creation Tests ===
# Move to a region where you have permission to build.
# '''Texture'''
## Upload a test image using the upload tool (Build->Upload->Image).
## When the upload is complete, apply that texture to an object.
## '''Verify''' that the image uploaded successfully.
# '''Sound'''
## Upload a test sound using the upload tool (Build->Upload->Sound)
## When the upload is complete, double click the sound in your inventory to play it back.
## '''Verify''' that the sound plays.
# '''Notecard'''
## In the inventory sidebar, click the "plus sign" (+) button at the bottom of the list of assets.
## In the menu that appears, select "New Notecard".
## Add some text in the body of the notecard and click save.
## Close the notecard
## Reopen the notecard from your inventory.
## '''Verify''' that the notecard text loads.
# '''Mesh'''
## Move to a mesh-enabled region.
## Select Build->Upload->Model to start the mesh upload process.
## In the file selection dialog, select the mesh object you prepared while setting up. The example file is named duck.dae.
## Select "Calculate weights & fee" at the bottom of the Upload Model dialog.
## After the upload fee has been calculated, select the "Upload" button.
## '''Verify''' that the mesh object is added to your inventory.
## Drag the mesh object out of your inventory onto the ground to rez it.
## '''Verify''' that the mesh object is rezzed.
# '''Object Creation'''
## Create a simple object using the build tools.
## '''Verify''' that the object is created
## '''Verify''' that you can take a copy of the created object into your inventory.
# '''Scripting'''
## Right click the object you created in the previous test and select edit.
## Select the content tab of the build floater.
## Click the New Script button.
## Double click the new script to edit.
## Edit the string "Hello, Avatar!" to be "Hi, Avatar!"
## Click save
## '''Verify''' that the script compiles.
## '''Verify''' that the object has sent the message "Hi, Avatar!".

=== Integrated Web Browser ===
# '''Browsing Test''' The integrated webkit browser should be able to browse while accessing the internet through a proxy.
## Enable the built-in browser. (Me->Preferences->Setup->"Use built-in browser", under "Web:".
## Enter a full url, like http://secondlife.com into text chat and send.
## Click the link in the text chat window.
## '''Verify''' that the built-in browser is able to access web content.

=== Media on a Prim ===
# '''Web Media'''
## '''Verify''' that web media is visible.
# '''Video Media'''
## '''Verify''' that video media is visible.

== Proxy Enabled, other HTTP through SOCKS 5 Proxy ==
# '''Repeat Connectivity Tests''' Verify that sending other HTTP traffic through the SOCKS 5 proxy works correctly.
## Rerun the following list of test cases, which are described in the section above.
### Viewer Initialization
### Avatar Navigation and Movement
### Avatar Communication
### Asset Download Tests
### Asset Upload Tests
### Integrated Web Browser
### Media On a Prim
## '''Verify''' that all tests pass.

== No Proxy Enabled ==
# '''Repeat Connectivity Tests''' Verify that users that are not using the proxy will not be negatively impacted by the change.
## Either test on another computer that is not firewalled, or relax the firewall restrictions on the testing network. If using the reference gateway configuration, run the ''nat_forward_all.sh'' script to allow traffic through without going through a proxy.
## Disable the proxy as described above.
## Rerun the following list of test cases, which are described in the section above.
### Viewer Initialization
### Avatar Navigation and Movement
### Avatar Communication
### Asset Download Tests
### Asset Upload Tests
### Integrated Web Browser
### Media On a Prim
## '''Verify''' that all tests pass.
## '''Verify''' that overall viewer performance is approximately the same as usual for the machine you are testing on.
## Re-enable the firewall if you disabled it before further testing.

== SOCKS 5 with Username/Password Authentication ==
# '''Successful Login with SOCKS Authentication''' Test that the viewer can connect when the SOCKS 5 host requires a password.
## Enable both proxies, with "other" traffic going through SOCKS 5.
## Also in the proxy settings floater, select Username/Password as the SOCKS Authentication method.
## Enter your SOCKS 5 username and password in the appropriate fields. If you followed the reference gateway instructions, your linux username and password should work for the socks credentials.
## Select OK.
## Try to log in to Second Life.
## '''Verify''' that login is successful.
## Leave authentication enabled for the next test.
## Optional: The previous set of connectivity tests could be run in this mode as well to verify that the Username/Password authentication method works as well. This is a lower priority than the other three modes because this configuration is behaviorally very similar to the no authentication test, and should either connect or not connect.
# '''SOCKS 5 Password Security''' The SOCKS 5 password should not be stored in cleartext.
## Leave SOCKS 5 authentication enabled in the viewer from the previous test.
## Close all running instances of the viewer.
## Navigate to the user's Second Life settings directory.
## Search, using grep or ctrl-f in notepad depending on the platform, for the username and password you used to connect to the SOCKS 5 server in the previous step in the settings.xml that corresponds to the viewer version you are testing with (settings.xml if using a release version, settings_development.xml if using a development build, etc).
## '''Verify''' that the username and password do not appear in the settings files.
## Start the viewer and disable authentication.

----


= Pass/Fail Criteria =
# '''Passes''' if
## No unexpected behaviors are observed
# '''Fails''' if
## Deviation from expected behavior is observed
## A bug is detected that was not accounted for by this test plan
## Performance degradation is observed when the proxy is disabled.
# '''Known Issues'''
## SLVoice does not support proxies, therefore voice is not expected to work when running the viewer behind a strict firewall that blocks the ports used for voice communication. If voice is enabled, an error message will appear when the viewer fails to connect to the voice server.

= Tear Down =
* Disable all proxies in the viewer configuration.

User:Log Linden/Socks5Viewer/TestPlan

2011-08-10T22:43:33Z

Log Linden: Added asset tests.

[[Category:Test Scripts]]
{| cellspacing="0" cellpadding="0" style="clear: {{{clear|right}}}; margin-bottom: .5em; float: right; padding: .5em 0 .8em 1.4em; background: none; width: {{{width|{{{1|auto}}}}}};" {{#if:{{{limit|}}}|class="toclimit-{{{limit}}}"}}
| __TOC__
|}
= Scope =
* This test is to verify that newly added proxy support in the viewer works as expected.
* The user story that prompted the changes is [https://jira.secondlife.com/browse/STORM-1112 STORM-1112 ].
* This test will only be meaningful if performed in a network environment that does not have access to second life.
* The test also requires a working web proxy host and SOCKS 5 proxy host.
* Estimated running time: 3 hours/platform after securing the appropriate test environment.

= Set-up =
== Environment ==
* Viewer: This test requires a build of the viewer that contains the Proxy code. Grab the latest for your platform from the link below:
{{ViewerInstallers|{{JiraIssue|STORM-1112|Implement SOCKS 5 proxy}}| Allow the Second Life Viewer to connect through a SOCKS 5 proxy. |task=log_viewer-socks5|repo=https://bitbucket.org/log_linden/viewer_socks5}}
* Server: The test requires testing of mesh upload and download functionality, so access to a region with mesh support is required. Agni or Aditi are each fine. Region crossing will also be tested, so adjacent regions to test in will also be required.
* A restrictive, firewalled network to connect the testing machine to is required to obtain valid test results.
* A working web proxy host and a working SOCKS 5 host are required to complete the test.
* Instructions to set up a reference Ubuntu Linux server that will act as a firewall and proxy gateway [[User:Log_Linden/Socks5Viewer/TestPlan/ProxyGateway | are available]].
* While 3rd party testers are welcome to set up a duplicate of our reference gateway server, we are also interested in results you might get in your organization's specific network setup, rather than using our reference setup. Since you might not be allowed to reconfigure your organization's firewall or proxy host, feel free to only test in the proxy configuration your organization supports and report on results you observe.

== Other ==
* Second Life account that is able to upload mesh assets on the grid being tested.
* Your avatar should be a member of a group and be allowed to send messages in that group for testing.
* Part of the test is making sure land parcel media is functional. Find somewhere in world that has botha
* Sandbox, or other area where building is allowed.
* Enable advanced mode. The proxy options are not available in basic mode.
* Have a test image file, sound file, and collada model available to test upload functionality. A sample collada model is available from the [collada.org website | https://collada.org/owl/download.php?sess=0&parent=126&expand=1&order=name&curview=0&binary=1&id=698/ ].

= Common Procedures =
Refer to this section when asked to do one of the following in a test step.
# '''Enable proxy connection with HTTP traffic sent through web proxy.'''
## Change these settings before logging into Second Life.
## Open the Proxy settings floater. Me->Preferences->Setup->"Adjust Proxy Settings"
## Check "Use HTTP Proxy for Web pages" and enter the address and port number.
## Check "Use SOCKS 5 Proxy for UDP traffic" and enter the address and port number.
## Under other HTTP traffic proxy, select "Use HTTP Proxy".
## Click OK.

# '''Enable proxy connection with HTTP traffic sent through SOCKS 5 proxy.'''
## Change these settings before logging into Second Life.
## Open the Proxy settings floater. Me->Preferences->Setup->"Adjust Proxy Settings"
## Check "Use HTTP Proxy for Web pages" and enter the address and port number.
## Check "Use SOCKS 5 Proxy for UDP traffic" and enter the address and port number.
## Under other HTTP traffic proxy, select "Use SOCKS 5 Proxy".
## Click OK.

# '''Disable all proxies'''
## Change these settings before logging into Second Life.
## Open the Proxy settings floater. Me->Preferences->Setup->"Adjust Proxy Settings"
## Uncheck "Use HTTP Proxy for Web pages".
## Uncheck "Use SOCKS 5 Proxy for UDP traffic".
## Click OK.

# '''Clear Viewer Caches'''
## Click the "Clear Cache" button on the advanced tab of the preferences floater.
## Confirm that you want to clear the cache.
## Restart the Viewer.

= Test Steps =
== Configuration Consistency Checks ==
# '''Expected Defaults''' Check the default configuration.
## step 1
## step 2
## '''Verify''' against expected behavior

== Proxy Enabled, other HTTP through Web Proxy ==
# Follow the instructions above to enable the proxy and send HTTP traffic through the web proxy.

=== Viewer Initialization ===
# '''HTTP Tables Loading''' Verify that the GPU table and feature table are able to be fetched by the proxy.
## Browse to the install directory of the viewer.
# '''Login Screen Renders Correctly
=== Avatar Navigation and Movement ===
# '''Walking'''
## '''Verify''' that your avatar can move around the world.
# '''Sitting'''
## '''Verify''' that your avatar can sit on objects.
# '''Flying'''
## '''Verify''' that you can fly around the region.
# '''World Map'''
## Open the World Map Floater (World->World Map).
## '''Verify''' that map tiles load and display the layout of the surrounding regions.
## '''Verify''' that green dots representing avatars are displayed.
## Close the World Map.
# '''Minimap'''
## Open the Mini-Map Floater (World->Mini-Map).
## '''Verify''' that map tiles are displayed.
# '''Region Crossing'''
## Fly or walk across a region boundary.
## '''Verify''' that you successfully arrive in the other region.
# '''Intra-region teleport'''
## Teleport by double clicking in the World Map floater, within the current region.
## '''Verify''' that you arrive in the place you clicked.
# '''Inter-region teleport'''
## Teleport by double clicking in the World Map floater, somewhere other than the current region.
## '''Verify''' that you arrive in the new region.

=== Avatar Communication ===
# '''Local Chat'''
## Try sending messages to others avatars standing nearby.
## '''Verify''' that the other people receive your messages and that you can receive messages from them.
# '''Group Chat'''
## Try sending messages to a group chat channel.
## '''Verify''' that you can send messages and receive other messages.
# '''IM'''
## Try sending private IM messages to another avatar.
## '''Verify''' that the other avatar receives your messages, and that you are able to receive their response.
# '''Display Names'''
## '''Verify''' that custom display names are visible for avatars that have them set.
=== Asset Download Tests ===
# Before starting this test, clear your viewer cache and relog.
# '''Texture'''
## '''Verify''' that textures load onto surfaces in your view.
# '''Sounds'''
## Locate the Button_click_down asset in your inventory. Double click the sound to play it.
## '''Verify''' that the sound plays.
# '''Notecard'''
## Locate the Community Standards notecard in the Library of your inventory.
## '''Verify''' that the notecard loads and is readable.
# '''Gestures'''
## Select a gesture from the "Gesture" menu at the bottom of the window.
## '''Verify''' that the gesture plays.
# '''Mesh'''
## Travel to a region with mesh assets available.
## '''Verify''' that the mesh assets rez and are visible.

# '''Legacy Fetch Methods'''
## Enable the Develop menu if you haven't already. (Me->Preferences->Advanced->Show Developer Menu)
## Disable HTTP Inventory and HTTP Textures in the Develop menu.
## Clear the viewer cache.
## Log back into Second Life.
## '''Verify''' that textures load onto surfaces in your view.
## '''Verify''' that your inventory loads.

=== Asset Creation Tests ===
# Move to a region where you have permission to build.
# '''Texture'''
## Upload a test image using the upload tool (Build->Upload->Image).
## When the upload is complete, apply that texture to an object.
## '''Verify''' that the image uploaded successfully.
# '''Sound'''
## Upload a test sound using the upload tool (Build->Upload->Sound)
## When the upload is complete, double click the sound in your inventory to play it back.
## '''Verify''' that the sound plays.
# '''Notecard'''
## In the inventory sidebar, click the "plus sign" (+) button at the bottom of the list of assets.
## In the menu that appears, select "New Notecard".
## Add some text in the body of the notecard and click save.
## Close the notecard
## Reopen the notecard from your inventory.
## '''Verify''' that the notecard text loads.
# '''Mesh'''
## Move to a mesh-enabled region.
## Select Build->Upload->Model to start the mesh upload process.
## In the file selection dialog, select the mesh object you prepared while setting up. The example file is named duck.dae.
## Select "Calculate weights & fee" at the bottom of the Upload Model dialog.
## After the upload fee has been calculated, select the "Upload" button.
## '''Verify''' that the mesh object is added to your inventory.
## Drag the mesh object out of your inventory onto the ground to rez it.
## '''Verify''' that the mesh object is rezzed.
# '''Object Creation'''
## Create a simple object using the build tools.
## '''Verify''' that the object is created
## '''Verify''' that you can take a copy of the created object into your inventory.
# '''Scripting'''
## Right click the object you created in the previous test and select edit.
## Select the content tab of the build floater.
## Click the New Script button.
## Double click the new script to edit.
## Edit the string "Hello, Avatar!" to be "Hi, Avatar!"
## Click save
## '''Verify''' that the script compiles.
## '''Verify''' that the object has sent the message "Hi, Avatar!".

=== Integrated Web Browser ===
# '''Browsing Test''' The integrated webkit browser can navigate web pages.
##

=== Media on a Prim ===
# '''Web Media'''
## '''Verify''' that web media is visible.
# '''Video Media'''
## '''Verify''' that video media is visible.

== Proxy Enabled, other HTTP through SOCKS 5 Proxy ==
# '''Repeat Connectivity Tests''' Verify that sending other HTTP traffic through the SOCKS 5 proxy works correctly.
## Rerun the following list of test cases, which are described in the section above.
### Viewer Initialization
### Avatar Navigation and Movement
### Avatar Communication
### Asset Download Tests
### Asset Upload Tests
### Integrated Web Browser
### Media On a Prim
## '''Verify''' that all tests pass.

== No Proxy Enabled ==
# '''Repeat Connectivity Tests''' Verify that users that are not using the proxy will not be negatively impacted by the change.
## Either test on another computer that is not firewalled, or relax the firewall restrictions on the testing network. If using the reference gateway configuration, run the ''nat_forward_all.sh'' script to allow traffic through without going through a proxy.
## Disable the proxy as described above.
## Rerun the following list of test cases, which are described in the section above.
### Viewer Initialization
### Avatar Navigation and Movement
### Avatar Communication
### Asset Download Tests
### Asset Upload Tests
### Integrated Web Browser
### Media On a Prim
## '''Verify''' that all tests pass.
## Re-enable the firewall if you disabled it before further testing.

== SOCKS 5 with Username/Password Authentication ==
# '''Successful Login with SOCKS Authentication''' Test that the viewer can connect when the SOCKS 5 host requires a password.
## Enable both proxies, with "other" traffic going through SOCKS 5.
## Also in the proxy settings floater, select Username/Password as the SOCKS Authentication method.
## Enter your SOCKS 5 username and password in the appropriate fields. If you followed the reference gateway instructions, your linux username and password should work for the socks credentials.
## Select OK.
## Try to log in to Second Life.
## '''Verify''' that login is successful.
## Leave authentication enabled for the next test.
## Optional: The previous set of connectivity tests could be run in this mode as well to verify that the Username/Password authentication method works as well. This is a lower priority than the other three modes because this configuration is behaviorally very similar to the no authentication test, and should either connect or not connect.
# '''SOCKS 5 Password Security''' The SOCKS 5 password should not be stored in cleartext.
## Leave SOCKS 5 authentication enabled in the viewer from the previous test.
## Close all running instances of the viewer.
## Navigate to the user's Second Life settings directory.
## Search, using grep or ctrl-f in notepad depending on the platform, for the username and password you used to connect to the SOCKS 5 server in the previous step in the settings.xml that corresponds to the viewer version you are testing with (settings.xml if using a release version, settings_development.xml if using a development build, etc).
## '''Verify''' that the username and password do not appear in the settings files.
## Start the viewer and disable authentication.

----


= Pass/Fail Criteria =
# '''Passes''' if
## No unexpected behaviors are observed
# '''Fails''' if
## Deviation from expected behavior is observed
## A bug is detected that was not accounted for by this test plan
## Performance degradation is observed when the proxy is disabled.
# '''Known Issues'''
## SLVoice does not support proxies, therefore voice is not expected to work when running the viewer behind a strict firewall that blocks the ports used for voice communication. If voice is enabled, an error message will appear when the viewer fails to connect to the voice server.

= Tear Down =
* Disable all proxies in the viewer configuration.

User:Log Linden/Socks5Viewer/TestPlan

2011-08-10T21:19:03Z

Log Linden: More fleshing out of the test cases.

User:Log Linden/Socks5Viewer/TestPlan/ProxyGateway

2011-08-10T20:10:21Z

Log Linden: /* Set up the SOCKS 5 proxy */

= Introduction =
These instructions will help you set up a simple Ubuntu gateway machine that will allow you to control access to the outside network for computers that are operating behind the gateway. This setup was created for testing the SOCKS 5 proxy. With some modification, the same setup could be used for testing various other network conditions, including throttling the connection speed down to something closer to residential DSL speeds. The instructions are intended for someone with a reasonable familiarity with Ubuntu Linux and will only discuss the customisations needed to set up the gateway.

= Requirements =
== Hardware ==
* A standard off-the-shelf PC with two Ethernet NICs
* 1 Ethernet switch for the "internal" network
* Network cables
* Other computers to actually test the viewer on.

== Software ==
* Ubuntu Linux 11.04 (Natty) [http://www.ubuntu.com/download/ubuntu/download install media] (Other flavors of Ubuntu, including Ubuntu server should work with these instructions as well.)

= Instructions =
== Connect network hardware ==
* Connect one network card to the outside network.
* Connect the other network card to the internal ethernet switch.
* Connect testing computers to the internal network switch.
[[File:Socks_test_setup.2.png|border|600px|SOCKS Testing Network Setup]]

== Install Ubuntu and Packages ==
* Install Ubuntu on the gateway machine. Consult the official Ubuntu install [https://help.ubuntu.com/community/GraphicalInstall instructions] for more information.
* Reboot into the installed system.
* Update the packages on the system.
<bash>
sudo apt-get update
sudo apt-get upgrade
</bash>
* Install some additional useful packages that we will need.
<bash> sudo apt-get install dnsmasq dante-server openssh </bash>
== Configure Network Interfaces ==
* IMPORTANT NOTE: For the purpose of this document, eth0 is the device that is connecting to the outside network, and eth1 is connecting to the internal network. Verify which is which on your setup.
<bash>ifconfig</bash>
Chances are, only one of the ethX devices will have been assigned an IP address by your network, this is the one connected to the external network. If this is not eth0 you need to either switch the network cables connected to the computer or remember to swap the interface names everywhere in the rest of this document. We are going to be assigning eth1 with a static IP address, which can cause problems if it conflicts with the rest of your network.
* Edit, with sudo, '/etc/network/interfaces' and replace its contents with the following
<bash>
auto lo eth0 eth1

iface lo inet loopback

# External network
iface eth0 inet dhcp

# Internal network
iface eth1 inet static
address 192.168.1.1
network 192.168.1.0
netmask 255.255.255.0
broadcast 192.168.1.255
</bash>
* This configuration makes eth0 continue to get its configuration through DHCP, and statically configures eth1. Listing both interfaces on the auto line will mean that they will automatically connect on startup.
* Because we are setting up the interfaces in this config file, we should probably prevent networkmanager from trying to do it as well.
<bash> sudo update-rc.d NetworkManager remove</bash>
* Restart the network
<bash>
sudo /etc/init.d/networking stop
sudo /etc/init.d/networking start
</bash>
* Verify the network configuration by looking for the correct IP addresses for eth0 and eth1.
<bash> ifconfig</bash>

== Set up DNS and DHCP ==
* dnsmasq is a lightweight combination DNS/DHCP server. For the anticipated number of clients for this network, it should be sufficient.
* Warning: Again, it is important to get the network interfaces correct for this. Running a rogue DHCP server on the wrong interface could cause major network problems. eth1 should be the '''internal''' network card.
* Replace /etc/dnsmasq.conf with the following:
<bash>
interface=eth1

dhcp-range=192.168.1.50,192.168.1.150,12h
dhcp-authoritative
dhcp-script=/bin/echo
</bash>
* Restart dnsmasq
<bash> sudo /etc/init.d/dnsmasq restart </bash>

== Set up the Firewall ==
* Save the following two scripts to ~/scripts
=== nat_forward_all.sh ===
<bash>
echo -e "\n\nLoading simple rc.firewall-iptables version $FWVER..\n"
DEPMOD=/sbin/depmod
MODPROBE=/sbin/modprobe

EXTIF="eth0"
INTIF="eth1"
echo " External Interface: $EXTIF"
echo " Internal Interface: $INTIF"

#======================================================================
#== No editing beyond this line is required for initial MASQ testing ==
echo -en " loading modules: "
echo " - Verifying that all kernel modules are ok"
$DEPMOD -a
echo "----------------------------------------------------------------------"
echo -en "ip_tables, "
$MODPROBE ip_tables
echo -en "nf_conntrack, "
$MODPROBE nf_conntrack
echo -en "nf_conntrack_ftp, "
$MODPROBE nf_conntrack_ftp
echo -en "nf_conntrack_irc, "
$MODPROBE nf_conntrack_irc
echo -en "iptable_nat, "
$MODPROBE iptable_nat
echo -en "nf_nat_ftp, "
$MODPROBE nf_nat_ftp
echo "----------------------------------------------------------------------"
echo -e " Done loading modules.\n"
echo " Enabling forwarding.."
echo "1" > /proc/sys/net/ipv4/ip_forward
echo " Enabling DynamicAddr.."
echo "1" > /proc/sys/net/ipv4/ip_dynaddr
echo " Clearing any existing rules and setting default policy.."

iptables-restore <<-EOF
*nat
-A POSTROUTING -o "$EXTIF" -j MASQUERADE
COMMIT
*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A FORWARD -i "$EXTIF" -o "$INTIF" -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -i "$INTIF" -o "$EXTIF" -j ACCEPT
-A FORWARD -j LOG
COMMIT
EOF

echo -e "\nrc.firewall-iptables v$FWVER done.\n"
</bash>
=== nat_block_all.sh ===
<bash>
echo -e "\n\nLoading simple rc.firewall-iptables version $FWVER..\n"
DEPMOD=/sbin/depmod
MODPROBE=/sbin/modprobe

EXTIF="eth0"
INTIF="eth1"
echo " External Interface: $EXTIF"
echo " Internal Interface: $INTIF"

#======================================================================
#== No editing beyond this line is required for initial MASQ testing ==
echo -en " loading modules: "
echo " - Verifying that all kernel modules are ok"
$DEPMOD -a
echo "----------------------------------------------------------------------"
echo -en "ip_tables, "
$MODPROBE ip_tables
echo -en "nf_conntrack, "
$MODPROBE nf_conntrack
echo -en "nf_conntrack_ftp, "
$MODPROBE nf_conntrack_ftp
echo -en "iptable_nat, "
$MODPROBE iptable_nat
echo -en "nf_nat_ftp, "
$MODPROBE nf_nat_ftp
echo "----------------------------------------------------------------------"
echo -e " Done loading modules.\n"
echo " Enabling forwarding.."
echo "1" > /proc/sys/net/ipv4/ip_forward
echo " Enabling DynamicAddr.."
echo "1" > /proc/sys/net/ipv4/ip_dynaddr
echo " Clearing any existing rules and setting default policy.."

iptables-restore <<-EOF
*nat
-A POSTROUTING -o "$EXTIF" -j MASQUERADE
COMMIT
*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A FORWARD -i "$INTIF" -j LOG
-A FORWARD -i "$INTIF" -j REJECT
COMMIT
EOF

echo -e "\nrc.firewall-iptables v$FWVER done.\n"
</bash>
* Make both scripts executable
<bash>
chmod a+x ~/scripts/nat_block_all.sh
chmod a+x ~/scripts/nat_forward_all.sh
</bash>
* Test the wide-open script. Inspect the output for errors indicating something is wrong.
<bash>
sudo ~/scripts/nat_forward_all.sh
</bash>
* If the previous command was successful and you got dns and dhcp configured before, you should be able to connect through your gateway on computers on the internal network.
* Test this now, by connecting a test computer to the network if you haven't already. Try browsing the web on one of the test machines as a quick test. Use '''ipconfig /all''' or '''ifconfig''' to see how the test computer is being configured. Expected values are below:
{| class="lltable" border="1"
|+ '''Test Machine Network Parameters'''

|--
!Parameter
!Expected Value

|--
| IP Address
| 192.168.1.50-192.168.1.150

|--
| Subnet Mask
| 255.255.255.0

|--
| Default Gateway
| 192.168.1.1

|--
| Nameserver (DNS Server)
| 192.168.1.1

|}

* If everything seems to be working correctly, make the wide-open config run during system startup.
<bash>
sudo cp nat_forward_all.sh /etc/init.d/nat.sh
sudo ln -s /etc/init.d/nat.sh /etc/rc2.d/S95masquradescript
</bash>

== Set up the SOCKS 5 proxy==
* Replace /etc/danted.conf with the following.
<pre>
logoutput: /var/log/dante.log

internal: eth1 port = 1080

external: eth0

method: username none
# Accept either username auth or no auth. If using username auth, use the same username and password that are used to sign on to this machine.

#user.privileged: proxy
user.notprivileged: nobody

### "client-rules" ###

client pass {
from: 192.168.1.0/24 port 1-65535 to: 0.0.0.0/0
}

client block {
from: 0.0.0.0/0 to: 0.0.0.0/0
log: connect error
}

### "socks-rules" ###
# Block connections to loopback interfaces
block {
from: 0.0.0.0/0 to: 127.0.0.0/8
log: connect error
}

# Allow udp reply packets from outside
pass {
from: 0.0.0.0/0 to: 192.168.1.0/24
command: udpreply
}

# Allow the internal network to connect to everything outside
pass {
from: 192.168.1.0/24 to: 0.0.0.0/0
protocol: tcp udp
}

# Block anything else
block {
from: 0.0.0.0/0 to: 0.0.0.0/0
log: connect error
}

</pre>
* Start the proxy server
<bash> sudo /etc/init.d/danted restart </bash>
* If you get a "Failed to open libc.so..." error message when starting the proxy server, this is caused by a [https://bugs.launchpad.net/ubuntu/+source/dante/+bug/767085 mistake] in the dante-server debian package. To work around this, create a simlink to the correct libc.so and try to start danted again.
<bash> sudo ln -sf /lib/i386-linux-gnu/libc-2.13.so /lib/i386-linux-gnu/libc.so </bash>
* Test connecting through the proxy by configuring the web browser on one of the test machines connected through the gateway to use the proxy.
* Restrict outgoing traffic through the gateway by enabling the more restrictive iptables configuration.
<bash> sudo ~/scripts/nat_block_all.sh </bash>
* In the proxy options section of the browser, supply 192.168.1.1 as the SOCKS server and 1080 as the port.
* Attempt to browse to an internet website. If you can browse as usual, the proxy is working correctly.
* Disable the proxy in the browser.

== Set up the HTTP (Web) proxy ==
=== Configure the HTTP proxy ===
* Edit /etc/squid/squid.conf. We will be editing the existing file instead of replacing it.
* Look for the following line:
http_port 3128
* Replace with the following:
http_port 192.168.1.1:3128
cache deny all
* Look for the following lines:
acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network

* Replace with
acl localnet src 192.168.1.0/8 # RFC1918 possible internal network

* Look for the following line:
acl CONNECT method CONNECT
* Append two lines after to make it look like this:
acl CONNECT method CONNECT
# Enable SSL via CONNECT
acl SSL method CONNECT

* Look for the following line:
http_access allow localhost
* Append another line after it so that it now looks like this:
http_access allow localhost
http_access allow localnet

* A patch to do the above:
<diff>
--- squid.conf.original 2011-07-11 13:58:12.640564821 -0400
+++ squid.conf 2011-07-13 18:44:17.324652415 -0400
@@ -606,8 +606,6 @@
# Example rule allowing access from your local networks.
# Adapt to list your (internal) IP networks from where browsing
# should be allowed
-acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
-acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
#
acl SSL_ports port 443 # https
@@ -628,6 +626,8 @@
acl Safe_ports port 901 # SWAT
acl purge method PURGE
acl CONNECT method CONNECT
+# Enable SSL via CONNECT
+acl SSL method CONNECT

# TAG: http_access
# Allowing or Denying access based on defined access lists
@@ -675,6 +675,8 @@
# from where browsing should be allowed
#http_access allow localnet
http_access allow localhost
+http_access allow localnet
+

# And finally deny all other access to this proxy
http_access deny all
@@ -1111,8 +1113,9 @@
# visible on the internal address.
#
# Squid normally listens to port 3128
-http_port 3128
+http_port 192.168.1.1:3128

+cache deny all
# TAG: https_port
# Note: This option is only available if Squid is rebuilt with the
# --enable-ssl option
</diff>

* Restart the squid proxy:
<bash>
sudo stop squid
sudo start squid
</bash>
* Examine syslog for any errors
<bash>
sudo tail /var/log/syslog
</bash>

=== Test the HTTP Proxy ===
* Restrict outgoing traffic through the gateway by enabling the more restrictive iptables configuration.
<bash> sudo ~/scripts/nat_block_all.sh </bash>
* In the proxy options section of the browser on the test machine, supply 192.168.1.1 as the HTTP and HTTPS proxy server with 3128 as the port in both cases.
* Remove any SOCKS proxy configuration in the browser.
* Attempt to browse to an internet website. Also try browsing to an https:// website such as [https://codereview.secondlife.com https://codereview.secondlife.com]. If you can browse as usual, the proxy is working correctly.
* Disable the proxy in the browser.

== Cleanup ==
* Reboot the machine, using the graphical menus to reboot or the following command. Verify that everything still works as before.
<bash> sudo shutdown -r now </bash>
* Note that we left the unrestricted firewall configuration as the default. When the gateway is rebooted, you will need to rerun '''~/scripts/nat_blocked_all.sh''' to restrict connections again. If you would like that to be the default state, copy '''~/scripts/nat_blocked_all.sh''' to '''/etc/init.d/nat.sh'''.

= Useful References =
If you run into difficulties with these instructions, there is more information in the official documentation. I based the configurations in this document mostly from the following sites:
*[https://help.ubuntu.com/community/Router Ubuntu Router Instructions]

User:Log Linden/Socks5Viewer/TestPlan

2011-08-09T22:05:57Z

Log Linden: Added more test steps skeleton.

User:Log Linden/Socks5Viewer/TestPlan

2011-08-09T21:42:22Z

Log Linden: /* Other */

User:Log Linden/Socks5Viewer/TestPlan

2011-08-09T21:41:30Z

Log Linden: Fleshed out the common procedures section

User:Log Linden/Socks5Viewer/TestPlan

2011-08-09T19:26:32Z

Log Linden: /* Pass/Fail Criteria */

User:Log Linden/Socks5Viewer/TestPlan/

2011-08-09T19:22:34Z

Log Linden: Redirected to the right address

#REDIRECT [[User:Log_Linden/Socks5Viewer/TestPlan]]

User:Log Linden/Socks5Viewer/TestPlan

2011-08-09T19:21:30Z

Log Linden:

User:Log Linden/Socks5Viewer/TestPlan/

2011-08-09T19:16:27Z

Log Linden: Fixed links

User:Log Linden/Socks5Viewer/TestPlan/

2011-08-09T19:12:36Z

Log Linden: Right aligned TOC

User:Log Linden/Socks5Viewer/TestPlan/

2011-08-09T18:39:26Z

Log Linden: Created page, added introductory sections, working on skeleton of test cases.

[[Category:Test Scripts]]
----

== Scope ==
* This test is to verify that newly added proxy support in the viewer works as expected.
* The user story that prompted the changes is [[STORM-1112 | https://jira.secondlife.com/browse/STORM-1112 ]]
* This test will only be meaningful if performed in a network environment that does not have access to second life.
* The test also requires a working web proxy host and SOCKS 5 proxy host.
* Estimated running time: 2 hours/platform after securing the appropriate test environment

== Set-up ==
=== Environment ===
* Viewer: This test requires a build of the viewer that contains the Proxy code. Grab the latest for your platform from the link below:
{{ViewerInstallers|{{JiraIssue|STORM-1112|Implement SOCKS 5 proxy}}| Allow the Second Life Viewer to connect through a SOCKS 5 proxy. |task=log_viewer-socks5|repo=https://bitbucket.org/log_linden/viewer_socks5}}
* Server: The test requires testing of mesh upload and download functionality, so access to a region with mesh support is required. Agni or Aditi are each fine. Region crossing will also be tested, so adjacent regions to test in will also be required.
* A restrictive, firewalled network to connect the testing machine to is required to obtain valid test results.
* A working web proxy host and a working SOCKS 5 host are required to complete the test.
* Instructions to set up a reference Ubuntu Linux server that will act as a firewall and proxy gateway are available on the wiki.
* While 3rd party testers are welcome to set up a duplicate of our reference gateway server, we are also interested in results you might get in your organization's specific network setup, rather than using our reference setup. Since you might not be allowed to reconfigure your organization's firewall or proxy host, feel free to only test in the proxy configuration your organization supports and report on results you observe.

=== Other ===
* Second Life Account that is able to upload mesh assets on the grid being tested.
* Sandbox, or other area where building is allowed.

== Common Procedures ==
Refer to this section when asked to do one of the following in a test step.
# '''Enable SOCKS 5 proxy '''
## step 1
## step 2
## '''Verify''' against expected behavior

# '''Clear Viewer Caches'''
## step 1
## step 2

== Test Steps ==
=== Functional Tests ===
# '''Test case 1''' (you can briefly outline the goal of the test case here)
## step 1
## step 2
## '''Verify''' against expected behavior
=== Functional Tests ===
# '''Test case 1''' (you can briefly outline the goal of the test case here)
## step 1
## step 2
## '''Verify''' against expected behavior
# '''Test case 2'''
## step 1
## step 2
## '''Verify''' against expected behavior
# '''Test case 3'''
## step 1
## step 2
## '''Verify''' against expected behavior
=== Functional Tests ===
# '''Test case 1''' (you can briefly outline the goal of the test case here)
## step 1
## step 2
## '''Verify''' against expected behavior
# '''Test case 2'''
## step 1
## step 2
## '''Verify''' against expected behavior
# '''Test case 3'''
## step 1
## step 2
## '''Verify''' against expected behavior

----


== Pass/Fail Criteria ==
# Passes if
## e.g. No unexpected behaviors are observed
# Fails if
## e.g. Expected behaviors are broken
## e.g. A bug is detected that was not accounted for by this test plan

== Tear Down ==
* Disable all proxies in the viewer configuration.

User:Log Linden/Socks5Viewer/TestPlan/ProxyGateway

2011-07-28T15:41:14Z

Log Linden: /* nat_block_all.sh */

= Introduction =
These instructions will help you set up a simple Ubuntu gateway machine that will allow you to control access to the outside network for computers that are operating behind the gateway. This setup was created for testing the SOCKS 5 proxy. With some modification, the same setup could be used for testing various other network conditions, including throttling the connection speed down to something closer to residential DSL speeds. The instructions are intended for someone with a reasonable familiarity with Ubuntu Linux and will only discuss the customisations needed to set up the gateway.

= Requirements =
== Hardware ==
* A standard off-the-shelf PC with two Ethernet NICs
* 1 Ethernet switch for the "internal" network
* Network cables
* Other computers to actually test the viewer on.

== Software ==
* Ubuntu Linux 11.04 (Natty) [http://www.ubuntu.com/download/ubuntu/download install media] (Other flavors of Ubuntu, including Ubuntu server should work with these instructions as well.)

= Instructions =
== Connect network hardware ==
* Connect one network card to the outside network.
* Connect the other network card to the internal ethernet switch.
* Connect testing computers to the internal network switch.
[[File:Socks_test_setup.2.png|border|600px|SOCKS Testing Network Setup]]

== Install Ubuntu and Packages ==
* Install Ubuntu on the gateway machine. Consult the official Ubuntu install [https://help.ubuntu.com/community/GraphicalInstall instructions] for more information.
* Reboot into the installed system.
* Update the packages on the system.
<bash>
sudo apt-get update
sudo apt-get upgrade
</bash>
* Install some additional useful packages that we will need.
<bash> sudo apt-get install dnsmasq dante-server openssh </bash>
== Configure Network Interfaces ==
* IMPORTANT NOTE: For the purpose of this document, eth0 is the device that is connecting to the outside network, and eth1 is connecting to the internal network. Verify which is which on your setup.
<bash>ifconfig</bash>
Chances are, only one of the ethX devices will have been assigned an IP address by your network, this is the one connected to the external network. If this is not eth0 you need to either switch the network cables connected to the computer or remember to swap the interface names everywhere in the rest of this document. We are going to be assigning eth1 with a static IP address, which can cause problems if it conflicts with the rest of your network.
* Edit, with sudo, '/etc/network/interfaces' and replace its contents with the following
<bash>
auto lo eth0 eth1

iface lo inet loopback

# External network
iface eth0 inet dhcp

# Internal network
iface eth1 inet static
address 192.168.1.1
network 192.168.1.0
netmask 255.255.255.0
broadcast 192.168.1.255
</bash>
* This configuration makes eth0 continue to get its configuration through DHCP, and statically configures eth1. Listing both interfaces on the auto line will mean that they will automatically connect on startup.
* Because we are setting up the interfaces in this config file, we should probably prevent networkmanager from trying to do it as well.
<bash> sudo update-rc.d NetworkManager remove</bash>
* Restart the network
<bash>
sudo /etc/init.d/networking stop
sudo /etc/init.d/networking start
</bash>
* Verify the network configuration by looking for the correct IP addresses for eth0 and eth1.
<bash> ifconfig</bash>

== Set up DNS and DHCP ==
* dnsmasq is a lightweight combination DNS/DHCP server. For the anticipated number of clients for this network, it should be sufficient.
* Warning: Again, it is important to get the network interfaces correct for this. Running a rogue DHCP server on the wrong interface could cause major network problems. eth1 should be the '''internal''' network card.
* Replace /etc/dnsmasq.conf with the following:
<bash>
interface=eth1

dhcp-range=192.168.1.50,192.168.1.150,12h
dhcp-authoritative
dhcp-script=/bin/echo
</bash>
* Restart dnsmasq
<bash> sudo /etc/init.d/dnsmasq restart </bash>

== Set up the Firewall ==
* Save the following two scripts to ~/scripts
=== nat_forward_all.sh ===
<bash>
echo -e "\n\nLoading simple rc.firewall-iptables version $FWVER..\n"
DEPMOD=/sbin/depmod
MODPROBE=/sbin/modprobe

EXTIF="eth0"
INTIF="eth1"
echo " External Interface: $EXTIF"
echo " Internal Interface: $INTIF"

#======================================================================
#== No editing beyond this line is required for initial MASQ testing ==
echo -en " loading modules: "
echo " - Verifying that all kernel modules are ok"
$DEPMOD -a
echo "----------------------------------------------------------------------"
echo -en "ip_tables, "
$MODPROBE ip_tables
echo -en "nf_conntrack, "
$MODPROBE nf_conntrack
echo -en "nf_conntrack_ftp, "
$MODPROBE nf_conntrack_ftp
echo -en "nf_conntrack_irc, "
$MODPROBE nf_conntrack_irc
echo -en "iptable_nat, "
$MODPROBE iptable_nat
echo -en "nf_nat_ftp, "
$MODPROBE nf_nat_ftp
echo "----------------------------------------------------------------------"
echo -e " Done loading modules.\n"
echo " Enabling forwarding.."
echo "1" > /proc/sys/net/ipv4/ip_forward
echo " Enabling DynamicAddr.."
echo "1" > /proc/sys/net/ipv4/ip_dynaddr
echo " Clearing any existing rules and setting default policy.."

iptables-restore <<-EOF
*nat
-A POSTROUTING -o "$EXTIF" -j MASQUERADE
COMMIT
*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A FORWARD -i "$EXTIF" -o "$INTIF" -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -i "$INTIF" -o "$EXTIF" -j ACCEPT
-A FORWARD -j LOG
COMMIT
EOF

echo -e "\nrc.firewall-iptables v$FWVER done.\n"
</bash>
=== nat_block_all.sh ===
<bash>
echo -e "\n\nLoading simple rc.firewall-iptables version $FWVER..\n"
DEPMOD=/sbin/depmod
MODPROBE=/sbin/modprobe

EXTIF="eth0"
INTIF="eth1"
echo " External Interface: $EXTIF"
echo " Internal Interface: $INTIF"

#======================================================================
#== No editing beyond this line is required for initial MASQ testing ==
echo -en " loading modules: "
echo " - Verifying that all kernel modules are ok"
$DEPMOD -a
echo "----------------------------------------------------------------------"
echo -en "ip_tables, "
$MODPROBE ip_tables
echo -en "nf_conntrack, "
$MODPROBE nf_conntrack
echo -en "nf_conntrack_ftp, "
$MODPROBE nf_conntrack_ftp
echo -en "iptable_nat, "
$MODPROBE iptable_nat
echo -en "nf_nat_ftp, "
$MODPROBE nf_nat_ftp
echo "----------------------------------------------------------------------"
echo -e " Done loading modules.\n"
echo " Enabling forwarding.."
echo "1" > /proc/sys/net/ipv4/ip_forward
echo " Enabling DynamicAddr.."
echo "1" > /proc/sys/net/ipv4/ip_dynaddr
echo " Clearing any existing rules and setting default policy.."

iptables-restore <<-EOF
*nat
-A POSTROUTING -o "$EXTIF" -j MASQUERADE
COMMIT
*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A FORWARD -i "$INTIF" -j LOG
-A FORWARD -i "$INTIF" -j REJECT
COMMIT
EOF

echo -e "\nrc.firewall-iptables v$FWVER done.\n"
</bash>
* Make both scripts executable
<bash>
chmod a+x ~/scripts/nat_block_all.sh
chmod a+x ~/scripts/nat_forward_all.sh
</bash>
* Test the wide-open script. Inspect the output for errors indicating something is wrong.
<bash>
sudo ~/scripts/nat_forward_all.sh
</bash>
* If the previous command was successful and you got dns and dhcp configured before, you should be able to connect through your gateway on computers on the internal network.
* Test this now, by connecting a test computer to the network if you haven't already. Try browsing the web on one of the test machines as a quick test. Use '''ipconfig /all''' or '''ifconfig''' to see how the test computer is being configured. Expected values are below:
{| class="lltable" border="1"
|+ '''Test Machine Network Parameters'''

|--
!Parameter
!Expected Value

|--
| IP Address
| 192.168.1.50-192.168.1.150

|--
| Subnet Mask
| 255.255.255.0

|--
| Default Gateway
| 192.168.1.1

|--
| Nameserver (DNS Server)
| 192.168.1.1

|}

* If everything seems to be working correctly, make the wide-open config run during system startup.
<bash>
sudo cp nat_forward_all.sh /etc/init.d/nat.sh
sudo ln -s /etc/init.d/nat.sh /etc/rc2.d/S95masquradescript
</bash>

== Set up the SOCKS 5 proxy==
* Replace /etc/danted.conf with the following.
<pre>
logoutput: /var/log/dante.log

internal: eth1 port = 1080

external: eth0

method: username none
#the above puts no username or password. Access will instead be controlled via client ip address/range.
#if there is no username or password - then danted socks server needs to run as nobody, i.e.

#user.privileged: proxy
user.notprivileged: nobody

### "client-rules" ###

client pass {
from: 192.168.1.0/24 port 1-65535 to: 0.0.0.0/0
}

client block {
from: 0.0.0.0/0 to: 0.0.0.0/0
log: connect error
}

### "socks-rules" ###
# Block connections to loopback interfaces
block {
from: 0.0.0.0/0 to: 127.0.0.0/8
log: connect error
}

# Allow udp reply packets from outside
pass {
from: 0.0.0.0/0 to: 192.168.1.0/24
command: udpreply
}

# Allow the internal network to connect to everything outside
pass {
from: 192.168.1.0/24 to: 0.0.0.0/0
protocol: tcp udp
}

# Block anything else
block {
from: 0.0.0.0/0 to: 0.0.0.0/0
log: connect error
}

</pre>
* Start the proxy server
<bash> sudo /etc/init.d/danted restart </bash>
* If you get a "Failed to open libc.so..." error message when starting the proxy server, this is caused by a [https://bugs.launchpad.net/ubuntu/+source/dante/+bug/767085 mistake] in the dante-server debian package. To work around this, create a simlink to the correct libc.so and try to start danted again.
<bash> sudo ln -sf /lib/i386-linux-gnu/libc-2.13.so /lib/i386-linux-gnu/libc.so </bash>
* Test connecting through the proxy by configuring the web browser on one of the test machines connected through the gateway to use the proxy.
* Restrict outgoing traffic through the gateway by enabling the more restrictive iptables configuration.
<bash> sudo ~/scripts/nat_block_all.sh </bash>
* In the proxy options section of the browser, supply 192.168.1.1 as the SOCKS server and 1080 as the port.
* Attempt to browse to an internet website. If you can browse as usual, the proxy is working correctly.
* Disable the proxy in the browser.

== Set up the HTTP (Web) proxy ==
=== Configure the HTTP proxy ===
* Edit /etc/squid/squid.conf. We will be editing the existing file instead of replacing it.
* Look for the following line:
http_port 3128
* Replace with the following:
http_port 192.168.1.1:3128
cache deny all
* Look for the following lines:
acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network

* Replace with
acl localnet src 192.168.1.0/8 # RFC1918 possible internal network

* Look for the following line:
acl CONNECT method CONNECT
* Append two lines after to make it look like this:
acl CONNECT method CONNECT
# Enable SSL via CONNECT
acl SSL method CONNECT

* Look for the following line:
http_access allow localhost
* Append another line after it so that it now looks like this:
http_access allow localhost
http_access allow localnet

* A patch to do the above:
<diff>
--- squid.conf.original 2011-07-11 13:58:12.640564821 -0400
+++ squid.conf 2011-07-13 18:44:17.324652415 -0400
@@ -606,8 +606,6 @@
# Example rule allowing access from your local networks.
# Adapt to list your (internal) IP networks from where browsing
# should be allowed
-acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
-acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
#
acl SSL_ports port 443 # https
@@ -628,6 +626,8 @@
acl Safe_ports port 901 # SWAT
acl purge method PURGE
acl CONNECT method CONNECT
+# Enable SSL via CONNECT
+acl SSL method CONNECT

# TAG: http_access
# Allowing or Denying access based on defined access lists
@@ -675,6 +675,8 @@
# from where browsing should be allowed
#http_access allow localnet
http_access allow localhost
+http_access allow localnet
+

# And finally deny all other access to this proxy
http_access deny all
@@ -1111,8 +1113,9 @@
# visible on the internal address.
#
# Squid normally listens to port 3128
-http_port 3128
+http_port 192.168.1.1:3128

+cache deny all
# TAG: https_port
# Note: This option is only available if Squid is rebuilt with the
# --enable-ssl option
</diff>

* Restart the squid proxy:
<bash>
sudo stop squid
sudo start squid
</bash>
* Examine syslog for any errors
<bash>
sudo tail /var/log/syslog
</bash>

=== Test the HTTP Proxy ===
* Restrict outgoing traffic through the gateway by enabling the more restrictive iptables configuration.
<bash> sudo ~/scripts/nat_block_all.sh </bash>
* In the proxy options section of the browser on the test machine, supply 192.168.1.1 as the HTTP and HTTPS proxy server with 3128 as the port in both cases.
* Remove any SOCKS proxy configuration in the browser.
* Attempt to browse to an internet website. Also try browsing to an https:// website such as [https://codereview.secondlife.com https://codereview.secondlife.com]. If you can browse as usual, the proxy is working correctly.
* Disable the proxy in the browser.

== Cleanup ==
* Reboot the machine, using the graphical menus to reboot or the following command. Verify that everything still works as before.
<bash> sudo shutdown -r now </bash>
* Note that we left the unrestricted firewall configuration as the default. When the gateway is rebooted, you will need to rerun '''~/scripts/nat_blocked_all.sh''' to restrict connections again. If you would like that to be the default state, copy '''~/scripts/nat_blocked_all.sh''' to '''/etc/init.d/nat.sh'''.

= Useful References =
If you run into difficulties with these instructions, there is more information in the official documentation. I based the configurations in this document mostly from the following sites:
*[https://help.ubuntu.com/community/Router Ubuntu Router Instructions]

User:Log Linden/Socks5Viewer/TestPlan/ProxyGateway

2011-07-27T21:58:10Z

Log Linden: /* Set up the SOCKS 5 proxy */

= Introduction =
These instructions will help you set up a simple Ubuntu gateway machine that will allow you to control access to the outside network for computers that are operating behind the gateway. This setup was created for testing the SOCKS 5 proxy. With some modification, the same setup could be used for testing various other network conditions, including throttling the connection speed down to something closer to residential DSL speeds. The instructions are intended for someone with a reasonable familiarity with Ubuntu Linux and will only discuss the customisations needed to set up the gateway.

= Requirements =
== Hardware ==
* A standard off-the-shelf PC with two Ethernet NICs
* 1 Ethernet switch for the "internal" network
* Network cables
* Other computers to actually test the viewer on.

== Software ==
* Ubuntu Linux 11.04 (Natty) [http://www.ubuntu.com/download/ubuntu/download install media] (Other flavors of Ubuntu, including Ubuntu server should work with these instructions as well.)

= Instructions =
== Connect network hardware ==
* Connect one network card to the outside network.
* Connect the other network card to the internal ethernet switch.
* Connect testing computers to the internal network switch.
[[File:Socks_test_setup.2.png|border|600px|SOCKS Testing Network Setup]]

== Install Ubuntu and Packages ==
* Install Ubuntu on the gateway machine. Consult the official Ubuntu install [https://help.ubuntu.com/community/GraphicalInstall instructions] for more information.
* Reboot into the installed system.
* Update the packages on the system.
<bash>
sudo apt-get update
sudo apt-get upgrade
</bash>
* Install some additional useful packages that we will need.
<bash> sudo apt-get install dnsmasq dante-server openssh </bash>
== Configure Network Interfaces ==
* IMPORTANT NOTE: For the purpose of this document, eth0 is the device that is connecting to the outside network, and eth1 is connecting to the internal network. Verify which is which on your setup.
<bash>ifconfig</bash>
Chances are, only one of the ethX devices will have been assigned an IP address by your network, this is the one connected to the external network. If this is not eth0 you need to either switch the network cables connected to the computer or remember to swap the interface names everywhere in the rest of this document. We are going to be assigning eth1 with a static IP address, which can cause problems if it conflicts with the rest of your network.
* Edit, with sudo, '/etc/network/interfaces' and replace its contents with the following
<bash>
auto lo eth0 eth1

iface lo inet loopback

# External network
iface eth0 inet dhcp

# Internal network
iface eth1 inet static
address 192.168.1.1
network 192.168.1.0
netmask 255.255.255.0
broadcast 192.168.1.255
</bash>
* This configuration makes eth0 continue to get its configuration through DHCP, and statically configures eth1. Listing both interfaces on the auto line will mean that they will automatically connect on startup.
* Because we are setting up the interfaces in this config file, we should probably prevent networkmanager from trying to do it as well.
<bash> sudo update-rc.d NetworkManager remove</bash>
* Restart the network
<bash>
sudo /etc/init.d/networking stop
sudo /etc/init.d/networking start
</bash>
* Verify the network configuration by looking for the correct IP addresses for eth0 and eth1.
<bash> ifconfig</bash>

== Set up DNS and DHCP ==
* dnsmasq is a lightweight combination DNS/DHCP server. For the anticipated number of clients for this network, it should be sufficient.
* Warning: Again, it is important to get the network interfaces correct for this. Running a rogue DHCP server on the wrong interface could cause major network problems. eth1 should be the '''internal''' network card.
* Replace /etc/dnsmasq.conf with the following:
<bash>
interface=eth1

dhcp-range=192.168.1.50,192.168.1.150,12h
dhcp-authoritative
dhcp-script=/bin/echo
</bash>
* Restart dnsmasq
<bash> sudo /etc/init.d/dnsmasq restart </bash>

== Set up the Firewall ==
* Save the following two scripts to ~/scripts
=== nat_forward_all.sh ===
<bash>
echo -e "\n\nLoading simple rc.firewall-iptables version $FWVER..\n"
DEPMOD=/sbin/depmod
MODPROBE=/sbin/modprobe

EXTIF="eth0"
INTIF="eth1"
echo " External Interface: $EXTIF"
echo " Internal Interface: $INTIF"

#======================================================================
#== No editing beyond this line is required for initial MASQ testing ==
echo -en " loading modules: "
echo " - Verifying that all kernel modules are ok"
$DEPMOD -a
echo "----------------------------------------------------------------------"
echo -en "ip_tables, "
$MODPROBE ip_tables
echo -en "nf_conntrack, "
$MODPROBE nf_conntrack
echo -en "nf_conntrack_ftp, "
$MODPROBE nf_conntrack_ftp
echo -en "nf_conntrack_irc, "
$MODPROBE nf_conntrack_irc
echo -en "iptable_nat, "
$MODPROBE iptable_nat
echo -en "nf_nat_ftp, "
$MODPROBE nf_nat_ftp
echo "----------------------------------------------------------------------"
echo -e " Done loading modules.\n"
echo " Enabling forwarding.."
echo "1" > /proc/sys/net/ipv4/ip_forward
echo " Enabling DynamicAddr.."
echo "1" > /proc/sys/net/ipv4/ip_dynaddr
echo " Clearing any existing rules and setting default policy.."

iptables-restore <<-EOF
*nat
-A POSTROUTING -o "$EXTIF" -j MASQUERADE
COMMIT
*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A FORWARD -i "$EXTIF" -o "$INTIF" -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -i "$INTIF" -o "$EXTIF" -j ACCEPT
-A FORWARD -j LOG
COMMIT
EOF

echo -e "\nrc.firewall-iptables v$FWVER done.\n"
</bash>
=== nat_block_all.sh ===
<bash>
echo -e "\n\nLoading simple rc.firewall-iptables version $FWVER..\n"
DEPMOD=/sbin/depmod
MODPROBE=/sbin/modprobe

EXTIF="eth0"
INTIF="eth1"
echo " External Interface: $EXTIF"
echo " Internal Interface: $INTIF"

#======================================================================
#== No editing beyond this line is required for initial MASQ testing ==
echo -en " loading modules: "
echo " - Verifying that all kernel modules are ok"
$DEPMOD -a
echo "----------------------------------------------------------------------"
echo -en "ip_tables, "
$MODPROBE ip_tables
echo -en "nf_conntrack, "
$MODPROBE nf_conntrack
echo -en "nf_conntrack_ftp, "
$MODPROBE nf_conntrack_ftp
echo -en "iptable_nat, "
$MODPROBE iptable_nat
echo -en "nf_nat_ftp, "
$MODPROBE nf_nat_ftp
echo "----------------------------------------------------------------------"
echo -e " Done loading modules.\n"
echo " Enabling forwarding.."
echo "1" > /proc/sys/net/ipv4/ip_forward
echo " Enabling DynamicAddr.."
echo "1" > /proc/sys/net/ipv4/ip_dynaddr
echo " Clearing any existing rules and setting default policy.."

iptables-restore <<-EOF
*nat
-A POSTROUTING -o "$EXTIF" -j MASQUERADE
COMMIT
*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A FORWARD -i "$INTIF" -j LOG
-A FORWARD -i "$INTIF" -j REJECT
COMMIT
EOF

echo -e "\nrc.firewall-iptables v$FWVER done.\n"
</bash>
* Make both scripts executable
<bash>
chmod a+x ~/scripts/nat_block_all.sh
chmod a+x ~/scripts/nat_forward_all.sh
</bash>
* Test the wide-open script. Inspect the output for errors indicating something is wrong.
<bash>
sudo ~/scripts/nat_forward_all.sh
</bash>
* If the previous command was successful and you got dns and dhcp configured before, you should be able to connect through your gateway on computers on the internal network.
* Test this now, by connecting a test computer to the network if you haven't already. Try browsing the web on one of the test machines as a quick test. Use '''ipconfig /all''' or '''ifconfig''' to see how the test computer is being configured. Expected values are below: 
{| class="lltable" border="1"
|+ '''Test Machine Network Parameters'''

|--
!Parameter
!Expected Value

|--
| IP Address
| 192.168.1.50-192.168.1.150

|--
| Subnet Mask
| 255.255.255.0

|--
| Default Gateway
| 192.168.1.1

|--
| Nameserver (DNS Server)
| 192.168.1.1

|}

* If everything seems to be working correctly, make the wide-open config run during system startup.
<bash>
sudo cp nat_forward_all.sh /etc/init.d/nat.sh
sudo ln -s /etc/init.d/nat.sh /etc/rc2.d/S95masquradescript
</bash>

== Set up the SOCKS 5 proxy==
* Replace /etc/danted.conf with the following.
<pre>
logoutput: /var/log/dante.log

internal: eth1 port = 1080

external: eth0

method: username none
#the above puts no username or password. Access will instead be controlled via client ip address/range.
#if there is no username or password - then danted socks server needs to run as nobody, i.e.

#user.privileged: proxy
user.notprivileged: nobody

### "client-rules" ###

client pass {
from: 192.168.1.0/24 port 1-65535 to: 0.0.0.0/0
}

client block {
from: 0.0.0.0/0 to: 0.0.0.0/0
log: connect error
}

### "socks-rules" ###
# Block connections to loopback interfaces
block {
from: 0.0.0.0/0 to: 127.0.0.0/8
log: connect error
}

# Allow udp reply packets from outside
pass {
from: 0.0.0.0/0 to: 192.168.1.0/24
command: udpreply
}

# Allow the internal network to connect to everything outside
pass {
from: 192.168.1.0/24 to: 0.0.0.0/0
protocol: tcp udp
}

# Block anything else
block {
from: 0.0.0.0/0 to: 0.0.0.0/0
log: connect error
}

</pre>
* Start the proxy server
<bash> sudo /etc/init.d/danted restart </bash>
* If you get a "Failed to open libc.so..." error message when starting the proxy server, this is caused by a [https://bugs.launchpad.net/ubuntu/+source/dante/+bug/767085 mistake] in the dante-server debian package. To work around this, create a simlink to the correct libc.so and try to start danted again.
<bash> sudo ln -sf /lib/i386-linux-gnu/libc-2.13.so /lib/i386-linux-gnu/libc.so </bash>
* Test connecting through the proxy by configuring the web browser on one of the test machines connected through the gateway to use the proxy.
* Restrict outgoing traffic through the gateway by enabling the more restrictive iptables configuration.
<bash> sudo ~/scripts/nat_block_all.sh </bash>
* In the proxy options section of the browser, supply 192.168.1.1 as the SOCKS server and 1080 as the port.
* Attempt to browse to an internet website. If you can browse as usual, the proxy is working correctly.
* Disable the proxy in the browser.

== Set up the HTTP (Web) proxy ==
=== Configure the HTTP proxy ===
* Edit /etc/squid/squid.conf. We will be editing the existing file instead of replacing it.
* Look for the following line:
http_port 3128
* Replace with the following:
http_port 192.168.1.1:3128
cache deny all
* Look for the following lines:
acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network

* Replace with
acl localnet src 192.168.1.0/8 # RFC1918 possible internal network

* Look for the following line:
acl CONNECT method CONNECT
* Append two lines after to make it look like this:
acl CONNECT method CONNECT
# Enable SSL via CONNECT
acl SSL method CONNECT

* Look for the following line:
http_access allow localhost
* Append another line after it so that it now looks like this:
http_access allow localhost
http_access allow localnet

* A patch to do the above:
<diff>
--- squid.conf.original 2011-07-11 13:58:12.640564821 -0400
+++ squid.conf 2011-07-13 18:44:17.324652415 -0400
@@ -606,8 +606,6 @@
# Example rule allowing access from your local networks.
# Adapt to list your (internal) IP networks from where browsing
# should be allowed
-acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
-acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
#
acl SSL_ports port 443 # https
@@ -628,6 +626,8 @@
acl Safe_ports port 901 # SWAT
acl purge method PURGE
acl CONNECT method CONNECT
+# Enable SSL via CONNECT
+acl SSL method CONNECT

# TAG: http_access
# Allowing or Denying access based on defined access lists
@@ -675,6 +675,8 @@
# from where browsing should be allowed
#http_access allow localnet
http_access allow localhost
+http_access allow localnet
+

# And finally deny all other access to this proxy
http_access deny all
@@ -1111,8 +1113,9 @@
# visible on the internal address.
#
# Squid normally listens to port 3128
-http_port 3128
+http_port 192.168.1.1:3128

+cache deny all
# TAG: https_port
# Note: This option is only available if Squid is rebuilt with the
# --enable-ssl option
</diff>

* Restart the squid proxy:
<bash>
sudo stop squid
sudo start squid
</bash>
* Examine syslog for any errors
<bash>
sudo tail /var/log/syslog
</bash>

=== Test the HTTP Proxy ===
* Restrict outgoing traffic through the gateway by enabling the more restrictive iptables configuration.
<bash> sudo ~/scripts/nat_block_all.sh </bash>
* In the proxy options section of the browser on the test machine, supply 192.168.1.1 as the HTTP and HTTPS proxy server with 3128 as the port in both cases.
* Remove any SOCKS proxy configuration in the browser.
* Attempt to browse to an internet website. Also try browsing to an https:// website such as [https://codereview.secondlife.com https://codereview.secondlife.com]. If you can browse as usual, the proxy is working correctly.
* Disable the proxy in the browser.

== Cleanup ==
* Reboot the machine, using the graphical menus to reboot or the following command. Verify that everything still works as before.
<bash> sudo shutdown -r now </bash>
* Note that we left the unrestricted firewall configuration as the default. When the gateway is rebooted, you will need to rerun '''~/scripts/nat_blocked_all.sh''' to restrict connections again. If you would like that to be the default state, copy '''~/scripts/nat_blocked_all.sh''' to '''/etc/init.d/nat.sh'''.

= Useful References =
If you run into difficulties with these instructions, there is more information in the official documentation. I based the configurations in this document mostly from the following sites:
*[https://help.ubuntu.com/community/Router Ubuntu Router Instructions]

User:Log Linden/Socks5Viewer/TestPlan/ProxyGateway

2011-07-27T20:10:14Z

Log Linden: /* Configure the HTTP proxy */

= Introduction =
These instructions will help you set up a simple Ubuntu gateway machine that will allow you to control access to the outside network for computers that are operating behind the gateway. This setup was created for testing the SOCKS 5 proxy. With some modification, the same setup could be used for testing various other network conditions, including throttling the connection speed down to something closer to residential DSL speeds. The instructions are intended for someone with a reasonable familiarity with Ubuntu Linux and will only discuss the customisations needed to set up the gateway.

= Requirements =
== Hardware ==
* A standard off-the-shelf PC with two Ethernet NICs
* 1 Ethernet switch for the "internal" network
* Network cables
* Other computers to actually test the viewer on.

== Software ==
* Ubuntu Linux 11.04 (Natty) [http://www.ubuntu.com/download/ubuntu/download install media] (Other flavors of Ubuntu, including Ubuntu server should work with these instructions as well.)

= Instructions =
== Connect network hardware ==
* Connect one network card to the outside network.
* Connect the other network card to the internal ethernet switch.
* Connect testing computers to the internal network switch.
[[File:Socks_test_setup.2.png|border|600px|SOCKS Testing Network Setup]]

== Install Ubuntu and Packages ==
* Install Ubuntu on the gateway machine. Consult the official Ubuntu install [https://help.ubuntu.com/community/GraphicalInstall instructions] for more information.
* Reboot into the installed system.
* Update the packages on the system.
<bash>
sudo apt-get update
sudo apt-get upgrade
</bash>
* Install some additional useful packages that we will need.
<bash> sudo apt-get install dnsmasq dante-server openssh </bash>
== Configure Network Interfaces ==
* IMPORTANT NOTE: For the purpose of this document, eth0 is the device that is connecting to the outside network, and eth1 is connecting to the internal network. Verify which is which on your setup.
<bash>ifconfig</bash>
Chances are, only one of the ethX devices will have been assigned an IP address by your network, this is the one connected to the external network. If this is not eth0 you need to either switch the network cables connected to the computer or remember to swap the interface names everywhere in the rest of this document. We are going to be assigning eth1 with a static IP address, which can cause problems if it conflicts with the rest of your network.
* Edit, with sudo, '/etc/network/interfaces' and replace its contents with the following
<bash>
auto lo eth0 eth1

iface lo inet loopback

# External network
iface eth0 inet dhcp

# Internal network
iface eth1 inet static
address 192.168.1.1
network 192.168.1.0
netmask 255.255.255.0
broadcast 192.168.1.255
</bash>
* This configuration makes eth0 continue to get its configuration through DHCP, and statically configures eth1. Listing both interfaces on the auto line will mean that they will automatically connect on startup.
* Because we are setting up the interfaces in this config file, we should probably prevent networkmanager from trying to do it as well.
<bash> sudo update-rc.d NetworkManager remove</bash>
* Restart the network
<bash>
sudo /etc/init.d/networking stop
sudo /etc/init.d/networking start
</bash>
* Verify the network configuration by looking for the correct IP addresses for eth0 and eth1.
<bash> ifconfig</bash>

== Set up DNS and DHCP ==
* dnsmasq is a lightweight combination DNS/DHCP server. For the anticipated number of clients for this network, it should be sufficient.
* Warning: Again, it is important to get the network interfaces correct for this. Running a rogue DHCP server on the wrong interface could cause major network problems. eth1 should be the '''internal''' network card.
* Replace /etc/dnsmasq.conf with the following:
<bash>
interface=eth1

dhcp-range=192.168.1.50,192.168.1.150,12h
dhcp-authoritative
dhcp-script=/bin/echo
</bash>
* Restart dnsmasq
<bash> sudo /etc/init.d/dnsmasq restart </bash>

== Set up the Firewall ==
* Save the following two scripts to ~/scripts
=== nat_forward_all.sh ===
<bash>
echo -e "\n\nLoading simple rc.firewall-iptables version $FWVER..\n"
DEPMOD=/sbin/depmod
MODPROBE=/sbin/modprobe

EXTIF="eth0"
INTIF="eth1"
echo " External Interface: $EXTIF"
echo " Internal Interface: $INTIF"

#======================================================================
#== No editing beyond this line is required for initial MASQ testing ==
echo -en " loading modules: "
echo " - Verifying that all kernel modules are ok"
$DEPMOD -a
echo "----------------------------------------------------------------------"
echo -en "ip_tables, "
$MODPROBE ip_tables
echo -en "nf_conntrack, "
$MODPROBE nf_conntrack
echo -en "nf_conntrack_ftp, "
$MODPROBE nf_conntrack_ftp
echo -en "nf_conntrack_irc, "
$MODPROBE nf_conntrack_irc
echo -en "iptable_nat, "
$MODPROBE iptable_nat
echo -en "nf_nat_ftp, "
$MODPROBE nf_nat_ftp
echo "----------------------------------------------------------------------"
echo -e " Done loading modules.\n"
echo " Enabling forwarding.."
echo "1" > /proc/sys/net/ipv4/ip_forward
echo " Enabling DynamicAddr.."
echo "1" > /proc/sys/net/ipv4/ip_dynaddr
echo " Clearing any existing rules and setting default policy.."

iptables-restore <<-EOF
*nat
-A POSTROUTING -o "$EXTIF" -j MASQUERADE
COMMIT
*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A FORWARD -i "$EXTIF" -o "$INTIF" -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -i "$INTIF" -o "$EXTIF" -j ACCEPT
-A FORWARD -j LOG
COMMIT
EOF

echo -e "\nrc.firewall-iptables v$FWVER done.\n"
</bash>
=== nat_block_all.sh ===
<bash>
echo -e "\n\nLoading simple rc.firewall-iptables version $FWVER..\n"
DEPMOD=/sbin/depmod
MODPROBE=/sbin/modprobe

EXTIF="eth0"
INTIF="eth1"
echo " External Interface: $EXTIF"
echo " Internal Interface: $INTIF"

#======================================================================
#== No editing beyond this line is required for initial MASQ testing ==
echo -en " loading modules: "
echo " - Verifying that all kernel modules are ok"
$DEPMOD -a
echo "----------------------------------------------------------------------"
echo -en "ip_tables, "
$MODPROBE ip_tables
echo -en "nf_conntrack, "
$MODPROBE nf_conntrack
echo -en "nf_conntrack_ftp, "
$MODPROBE nf_conntrack_ftp
echo -en "iptable_nat, "
$MODPROBE iptable_nat
echo -en "nf_nat_ftp, "
$MODPROBE nf_nat_ftp
echo "----------------------------------------------------------------------"
echo -e " Done loading modules.\n"
echo " Enabling forwarding.."
echo "1" > /proc/sys/net/ipv4/ip_forward
echo " Enabling DynamicAddr.."
echo "1" > /proc/sys/net/ipv4/ip_dynaddr
echo " Clearing any existing rules and setting default policy.."

iptables-restore <<-EOF
*nat
-A POSTROUTING -o "$EXTIF" -j MASQUERADE
COMMIT
*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A FORWARD -i "$INTIF" -j LOG
-A FORWARD -i "$INTIF" -j REJECT
COMMIT
EOF

echo -e "\nrc.firewall-iptables v$FWVER done.\n"
</bash>
* Make both scripts executable
<bash>
chmod a+x ~/scripts/nat_block_all.sh
chmod a+x ~/scripts/nat_forward_all.sh
</bash>
* Test the wide-open script. Inspect the output for errors indicating something is wrong.
<bash>
sudo ~/scripts/nat_forward_all.sh
</bash>
* If the previous command was successful and you got dns and dhcp configured before, you should be able to connect through your gateway on computers on the internal network.
* Test this now, by connecting a test computer to the network if you haven't already. Try browsing the web on one of the test machines as a quick test. Use '''ipconfig /all''' or '''ifconfig''' to see how the test computer is being configured. Expected values are below: 
{| class="lltable" border="1"
|+ '''Test Machine Network Parameters'''

|--
!Parameter
!Expected Value

|--
| IP Address
| 192.168.1.50-192.168.1.150

|--
| Subnet Mask
| 255.255.255.0

|--
| Default Gateway
| 192.168.1.1

|--
| Nameserver (DNS Server)
| 192.168.1.1

|}

* If everything seems to be working correctly, make the wide-open config run during system startup.
<bash>
sudo cp nat_forward_all.sh /etc/init.d/nat.sh
sudo ln -s /etc/init.d/nat.sh /etc/rc2.d/S95masquradescript
</bash>

== Set up the SOCKS 5 proxy==
* Replace /etc/danted.conf with the following.
<pre>
logoutput: /var/log/dante.log

internal: eth1 port = 1080

external: eth0

method: username none
#the above puts no username or password. Access will instead be controlled via client ip address/range.
#if there is no username or password - then danted socks server needs to run as nobody, i.e.

#user.privileged: proxy
user.notprivileged: nobody

### "client-rules" ###

client pass {
from: 192.168.1.0/16 port 1-65535 to: 0.0.0.0/0
}

client block {
from: 0.0.0.0/0 to: 0.0.0.0/0
log: connect error
}

### "socks-rules" ###
# Block connections to loopback interfaces
block {
from: 0.0.0.0/0 to: 127.0.0.0/8
log: connect error
}

# Allow udp reply packets from outside
pass {
from: 0.0.0.0/0 to: 192.168.1.0/16
command: udpreply
}

# Allow the internal network to connect to everything outside
pass {
from: 192.168.1.0/16 to: 0.0.0.0/0
protocol: tcp udp
}

# Block anything else
block {
from: 0.0.0.0/0 to: 0.0.0.0/0
log: connect error
}

</pre>
* Start the proxy server
<bash> sudo /etc/init.d/danted restart </bash>
* If you get a "Failed to open libc.so..." error message when starting the proxy server, this is caused by a [https://bugs.launchpad.net/ubuntu/+source/dante/+bug/767085 mistake] in the dante-server debian package. To work around this, create a simlink to the correct libc.so and try to start danted again.
<bash> sudo ln -sf /lib/i386-linux-gnu/libc-2.13.so /lib/i386-linux-gnu/libc.so </bash>
* Test connecting through the proxy by configuring the web browser on one of the test machines connected through the gateway to use the proxy.
* Restrict outgoing traffic through the gateway by enabling the more restrictive iptables configuration.
<bash> sudo ~/scripts/nat_block_all.sh </bash>
* In the proxy options section of the browser, supply 192.168.1.1 as the SOCKS server and 1080 as the port.
* Attempt to browse to an internet website. If you can browse as usual, the proxy is working correctly.
* Disable the proxy in the browser.

== Set up the HTTP (Web) proxy ==
=== Configure the HTTP proxy ===
* Edit /etc/squid/squid.conf. We will be editing the existing file instead of replacing it.
* Look for the following line:
http_port 3128
* Replace with the following:
http_port 192.168.1.1:3128
cache deny all
* Look for the following lines:
acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network

* Replace with
acl localnet src 192.168.1.0/8 # RFC1918 possible internal network

* Look for the following line:
acl CONNECT method CONNECT
* Append two lines after to make it look like this:
acl CONNECT method CONNECT
# Enable SSL via CONNECT
acl SSL method CONNECT

* Look for the following line:
http_access allow localhost
* Append another line after it so that it now looks like this:
http_access allow localhost
http_access allow localnet

* A patch to do the above:
<diff>
--- squid.conf.original 2011-07-11 13:58:12.640564821 -0400
+++ squid.conf 2011-07-13 18:44:17.324652415 -0400
@@ -606,8 +606,6 @@
# Example rule allowing access from your local networks.
# Adapt to list your (internal) IP networks from where browsing
# should be allowed
-acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
-acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
#
acl SSL_ports port 443 # https
@@ -628,6 +626,8 @@
acl Safe_ports port 901 # SWAT
acl purge method PURGE
acl CONNECT method CONNECT
+# Enable SSL via CONNECT
+acl SSL method CONNECT

# TAG: http_access
# Allowing or Denying access based on defined access lists
@@ -675,6 +675,8 @@
# from where browsing should be allowed
#http_access allow localnet
http_access allow localhost
+http_access allow localnet
+

# And finally deny all other access to this proxy
http_access deny all
@@ -1111,8 +1113,9 @@
# visible on the internal address.
#
# Squid normally listens to port 3128
-http_port 3128
+http_port 192.168.1.1:3128

+cache deny all
# TAG: https_port
# Note: This option is only available if Squid is rebuilt with the
# --enable-ssl option
</diff>

* Restart the squid proxy:
<bash>
sudo stop squid
sudo start squid
</bash>
* Examine syslog for any errors
<bash>
sudo tail /var/log/syslog
</bash>

=== Test the HTTP Proxy ===
* Restrict outgoing traffic through the gateway by enabling the more restrictive iptables configuration.
<bash> sudo ~/scripts/nat_block_all.sh </bash>
* In the proxy options section of the browser on the test machine, supply 192.168.1.1 as the HTTP and HTTPS proxy server with 3128 as the port in both cases.
* Remove any SOCKS proxy configuration in the browser.
* Attempt to browse to an internet website. Also try browsing to an https:// website such as [https://codereview.secondlife.com https://codereview.secondlife.com]. If you can browse as usual, the proxy is working correctly.
* Disable the proxy in the browser.

== Cleanup ==
* Reboot the machine, using the graphical menus to reboot or the following command. Verify that everything still works as before.
<bash> sudo shutdown -r now </bash>
* Note that we left the unrestricted firewall configuration as the default. When the gateway is rebooted, you will need to rerun '''~/scripts/nat_blocked_all.sh''' to restrict connections again. If you would like that to be the default state, copy '''~/scripts/nat_blocked_all.sh''' to '''/etc/init.d/nat.sh'''.

= Useful References =
If you run into difficulties with these instructions, there is more information in the official documentation. I based the configurations in this document mostly from the following sites:
*[https://help.ubuntu.com/community/Router Ubuntu Router Instructions]

User:Log Linden/Socks5Viewer/TestPlan/ProxyGateway

2011-07-27T19:58:22Z

Log Linden: /* Configure the HTTP proxy */ fixed instruction to disable cacheing of fetched items.

= Introduction =
These instructions will help you set up a simple Ubuntu gateway machine that will allow you to control access to the outside network for computers that are operating behind the gateway. This setup was created for testing the SOCKS 5 proxy. With some modification, the same setup could be used for testing various other network conditions, including throttling the connection speed down to something closer to residential DSL speeds. The instructions are intended for someone with a reasonable familiarity with Ubuntu Linux and will only discuss the customisations needed to set up the gateway.

= Requirements =
== Hardware ==
* A standard off-the-shelf PC with two Ethernet NICs
* 1 Ethernet switch for the "internal" network
* Network cables
* Other computers to actually test the viewer on.

== Software ==
* Ubuntu Linux 11.04 (Natty) [http://www.ubuntu.com/download/ubuntu/download install media] (Other flavors of Ubuntu, including Ubuntu server should work with these instructions as well.)

= Instructions =
== Connect network hardware ==
* Connect one network card to the outside network.
* Connect the other network card to the internal ethernet switch.
* Connect testing computers to the internal network switch.
[[File:Socks_test_setup.2.png|border|600px|SOCKS Testing Network Setup]]

== Install Ubuntu and Packages ==
* Install Ubuntu on the gateway machine. Consult the official Ubuntu install [https://help.ubuntu.com/community/GraphicalInstall instructions] for more information.
* Reboot into the installed system.
* Update the packages on the system.
<bash>
sudo apt-get update
sudo apt-get upgrade
</bash>
* Install some additional useful packages that we will need.
<bash> sudo apt-get install dnsmasq dante-server openssh </bash>
== Configure Network Interfaces ==
* IMPORTANT NOTE: For the purpose of this document, eth0 is the device that is connecting to the outside network, and eth1 is connecting to the internal network. Verify which is which on your setup.
<bash>ifconfig</bash>
Chances are, only one of the ethX devices will have been assigned an IP address by your network, this is the one connected to the external network. If this is not eth0 you need to either switch the network cables connected to the computer or remember to swap the interface names everywhere in the rest of this document. We are going to be assigning eth1 with a static IP address, which can cause problems if it conflicts with the rest of your network.
* Edit, with sudo, '/etc/network/interfaces' and replace its contents with the following
<bash>
auto lo eth0 eth1

iface lo inet loopback

# External network
iface eth0 inet dhcp

# Internal network
iface eth1 inet static
address 192.168.1.1
network 192.168.1.0
netmask 255.255.255.0
broadcast 192.168.1.255
</bash>
* This configuration makes eth0 continue to get its configuration through DHCP, and statically configures eth1. Listing both interfaces on the auto line will mean that they will automatically connect on startup.
* Because we are setting up the interfaces in this config file, we should probably prevent networkmanager from trying to do it as well.
<bash> sudo update-rc.d NetworkManager remove</bash>
* Restart the network
<bash>
sudo /etc/init.d/networking stop
sudo /etc/init.d/networking start
</bash>
* Verify the network configuration by looking for the correct IP addresses for eth0 and eth1.
<bash> ifconfig</bash>

== Set up DNS and DHCP ==
* dnsmasq is a lightweight combination DNS/DHCP server. For the anticipated number of clients for this network, it should be sufficient.
* Warning: Again, it is important to get the network interfaces correct for this. Running a rogue DHCP server on the wrong interface could cause major network problems. eth1 should be the '''internal''' network card.
* Replace /etc/dnsmasq.conf with the following:
<bash>
interface=eth1

dhcp-range=192.168.1.50,192.168.1.150,12h
dhcp-authoritative
dhcp-script=/bin/echo
</bash>
* Restart dnsmasq
<bash> sudo /etc/init.d/dnsmasq restart </bash>

== Set up the Firewall ==
* Save the following two scripts to ~/scripts
=== nat_forward_all.sh ===
<bash>
echo -e "\n\nLoading simple rc.firewall-iptables version $FWVER..\n"
DEPMOD=/sbin/depmod
MODPROBE=/sbin/modprobe

EXTIF="eth0"
INTIF="eth1"
echo " External Interface: $EXTIF"
echo " Internal Interface: $INTIF"

#======================================================================
#== No editing beyond this line is required for initial MASQ testing ==
echo -en " loading modules: "
echo " - Verifying that all kernel modules are ok"
$DEPMOD -a
echo "----------------------------------------------------------------------"
echo -en "ip_tables, "
$MODPROBE ip_tables
echo -en "nf_conntrack, "
$MODPROBE nf_conntrack
echo -en "nf_conntrack_ftp, "
$MODPROBE nf_conntrack_ftp
echo -en "nf_conntrack_irc, "
$MODPROBE nf_conntrack_irc
echo -en "iptable_nat, "
$MODPROBE iptable_nat
echo -en "nf_nat_ftp, "
$MODPROBE nf_nat_ftp
echo "----------------------------------------------------------------------"
echo -e " Done loading modules.\n"
echo " Enabling forwarding.."
echo "1" > /proc/sys/net/ipv4/ip_forward
echo " Enabling DynamicAddr.."
echo "1" > /proc/sys/net/ipv4/ip_dynaddr
echo " Clearing any existing rules and setting default policy.."

iptables-restore <<-EOF
*nat
-A POSTROUTING -o "$EXTIF" -j MASQUERADE
COMMIT
*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A FORWARD -i "$EXTIF" -o "$INTIF" -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -i "$INTIF" -o "$EXTIF" -j ACCEPT
-A FORWARD -j LOG
COMMIT
EOF

echo -e "\nrc.firewall-iptables v$FWVER done.\n"
</bash>
=== nat_block_all.sh ===
<bash>
echo -e "\n\nLoading simple rc.firewall-iptables version $FWVER..\n"
DEPMOD=/sbin/depmod
MODPROBE=/sbin/modprobe

EXTIF="eth0"
INTIF="eth1"
echo " External Interface: $EXTIF"
echo " Internal Interface: $INTIF"

#======================================================================
#== No editing beyond this line is required for initial MASQ testing ==
echo -en " loading modules: "
echo " - Verifying that all kernel modules are ok"
$DEPMOD -a
echo "----------------------------------------------------------------------"
echo -en "ip_tables, "
$MODPROBE ip_tables
echo -en "nf_conntrack, "
$MODPROBE nf_conntrack
echo -en "nf_conntrack_ftp, "
$MODPROBE nf_conntrack_ftp
echo -en "iptable_nat, "
$MODPROBE iptable_nat
echo -en "nf_nat_ftp, "
$MODPROBE nf_nat_ftp
echo "----------------------------------------------------------------------"
echo -e " Done loading modules.\n"
echo " Enabling forwarding.."
echo "1" > /proc/sys/net/ipv4/ip_forward
echo " Enabling DynamicAddr.."
echo "1" > /proc/sys/net/ipv4/ip_dynaddr
echo " Clearing any existing rules and setting default policy.."

iptables-restore <<-EOF
*nat
-A POSTROUTING -o "$EXTIF" -j MASQUERADE
COMMIT
*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A FORWARD -i "$INTIF" -j LOG
-A FORWARD -i "$INTIF" -j REJECT
COMMIT
EOF

echo -e "\nrc.firewall-iptables v$FWVER done.\n"
</bash>
* Make both scripts executable
<bash>
chmod a+x ~/scripts/nat_block_all.sh
chmod a+x ~/scripts/nat_forward_all.sh
</bash>
* Test the wide-open script. Inspect the output for errors indicating something is wrong.
<bash>
sudo ~/scripts/nat_forward_all.sh
</bash>
* If the previous command was successful and you got dns and dhcp configured before, you should be able to connect through your gateway on computers on the internal network.
* Test this now, by connecting a test computer to the network if you haven't already. Try browsing the web on one of the test machines as a quick test. Use '''ipconfig /all''' or '''ifconfig''' to see how the test computer is being configured. Expected values are below: 
{| class="lltable" border="1"
|+ '''Test Machine Network Parameters'''

|--
!Parameter
!Expected Value

|--
| IP Address
| 192.168.1.50-192.168.1.150

|--
| Subnet Mask
| 255.255.255.0

|--
| Default Gateway
| 192.168.1.1

|--
| Nameserver (DNS Server)
| 192.168.1.1

|}

* If everything seems to be working correctly, make the wide-open config run during system startup.
<bash>
sudo cp nat_forward_all.sh /etc/init.d/nat.sh
sudo ln -s /etc/init.d/nat.sh /etc/rc2.d/S95masquradescript
</bash>

== Set up the SOCKS 5 proxy==
* Replace /etc/danted.conf with the following.
<pre>
logoutput: /var/log/dante.log

internal: eth1 port = 1080

external: eth0

method: username none
#the above puts no username or password. Access will instead be controlled via client ip address/range.
#if there is no username or password - then danted socks server needs to run as nobody, i.e.

#user.privileged: proxy
user.notprivileged: nobody

### "client-rules" ###

client pass {
from: 192.168.1.0/16 port 1-65535 to: 0.0.0.0/0
}

client block {
from: 0.0.0.0/0 to: 0.0.0.0/0
log: connect error
}

### "socks-rules" ###
# Block connections to loopback interfaces
block {
from: 0.0.0.0/0 to: 127.0.0.0/8
log: connect error
}

# Allow udp reply packets from outside
pass {
from: 0.0.0.0/0 to: 192.168.1.0/16
command: udpreply
}

# Allow the internal network to connect to everything outside
pass {
from: 192.168.1.0/16 to: 0.0.0.0/0
protocol: tcp udp
}

# Block anything else
block {
from: 0.0.0.0/0 to: 0.0.0.0/0
log: connect error
}

</pre>
* Start the proxy server
<bash> sudo /etc/init.d/danted restart </bash>
* If you get a "Failed to open libc.so..." error message when starting the proxy server, this is caused by a [https://bugs.launchpad.net/ubuntu/+source/dante/+bug/767085 mistake] in the dante-server debian package. To work around this, create a simlink to the correct libc.so and try to start danted again.
<bash> sudo ln -sf /lib/i386-linux-gnu/libc-2.13.so /lib/i386-linux-gnu/libc.so </bash>
* Test connecting through the proxy by configuring the web browser on one of the test machines connected through the gateway to use the proxy.
* Restrict outgoing traffic through the gateway by enabling the more restrictive iptables configuration.
<bash> sudo ~/scripts/nat_block_all.sh </bash>
* In the proxy options section of the browser, supply 192.168.1.1 as the SOCKS server and 1080 as the port.
* Attempt to browse to an internet website. If you can browse as usual, the proxy is working correctly.
* Disable the proxy in the browser.

== Set up the HTTP (Web) proxy ==
=== Configure the HTTP proxy ===
* Edit /etc/squid/squid.conf. We will be editing the existing file instead of replacing it.
* Look for the following line:
http_port 3128
* Replace with the following:
http_port 192.168.1.1:3128
cache deny all
* Look for the following lines:
acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network

* Replace with
acl localnet src 192.168.1.0/8 # RFC1918 possible internal network

* Look for the following line:
acl CONNECT method CONNECT
* Append two lines to make it be:
acl CONNECT method CONNECT
# Enable SSL via CONNECT
acl SSL method CONNECT

* Look for the following line:
http_access allow localhost
* Append another line after it so that it now looks like this:
http_access allow localhost
http_access allow localnet

* A patch to do the above:
<diff>
--- squid.conf.original 2011-07-11 13:58:12.640564821 -0400
+++ squid.conf 2011-07-13 18:44:17.324652415 -0400
@@ -606,8 +606,6 @@
# Example rule allowing access from your local networks.
# Adapt to list your (internal) IP networks from where browsing
# should be allowed
-acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
-acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
#
acl SSL_ports port 443 # https
@@ -628,6 +626,8 @@
acl Safe_ports port 901 # SWAT
acl purge method PURGE
acl CONNECT method CONNECT
+# Enable SSL via CONNECT
+acl SSL method CONNECT

# TAG: http_access
# Allowing or Denying access based on defined access lists
@@ -675,6 +675,8 @@
# from where browsing should be allowed
#http_access allow localnet
http_access allow localhost
+http_access allow localnet
+

# And finally deny all other access to this proxy
http_access deny all
@@ -1111,8 +1113,9 @@
# visible on the internal address.
#
# Squid normally listens to port 3128
-http_port 3128
+http_port 192.168.1.1:3128

+cache deny all
# TAG: https_port
# Note: This option is only available if Squid is rebuilt with the
# --enable-ssl option
</diff>

* Restart the squid proxy:
<bash>
sudo stop squid
sudo start squid
</bash>
* Examine syslog for any errors
<bash>
sudo tail /var/log/syslog
</bash>

=== Test the HTTP Proxy ===
* Restrict outgoing traffic through the gateway by enabling the more restrictive iptables configuration.
<bash> sudo ~/scripts/nat_block_all.sh </bash>
* In the proxy options section of the browser on the test machine, supply 192.168.1.1 as the HTTP and HTTPS proxy server with 3128 as the port in both cases.
* Remove any SOCKS proxy configuration in the browser.
* Attempt to browse to an internet website. Also try browsing to an https:// website such as [https://codereview.secondlife.com https://codereview.secondlife.com]. If you can browse as usual, the proxy is working correctly.
* Disable the proxy in the browser.

== Cleanup ==
* Reboot the machine, using the graphical menus to reboot or the following command. Verify that everything still works as before.
<bash> sudo shutdown -r now </bash>
* Note that we left the unrestricted firewall configuration as the default. When the gateway is rebooted, you will need to rerun '''~/scripts/nat_blocked_all.sh''' to restrict connections again. If you would like that to be the default state, copy '''~/scripts/nat_blocked_all.sh''' to '''/etc/init.d/nat.sh'''.

= Useful References =
If you run into difficulties with these instructions, there is more information in the official documentation. I based the configurations in this document mostly from the following sites:
*[https://help.ubuntu.com/community/Router Ubuntu Router Instructions]

User:Log Linden/Socks5Viewer/TestPlan/ProxyGateway

2011-07-27T15:48:24Z

Log Linden: /* Set up the SOCKS 5 proxy */ Changed danted.conf to allow udp replies.

= Introduction =
These instructions will help you set up a simple Ubuntu gateway machine that will allow you to control access to the outside network for computers that are operating behind the gateway. This setup was created for testing the SOCKS 5 proxy. With some modification, the same setup could be used for testing various other network conditions, including throttling the connection speed down to something closer to residential DSL speeds. The instructions are intended for someone with a reasonable familiarity with Ubuntu Linux and will only discuss the customisations needed to set up the gateway.

= Requirements =
== Hardware ==
* A standard off-the-shelf PC with two Ethernet NICs
* 1 Ethernet switch for the "internal" network
* Network cables
* Other computers to actually test the viewer on.

== Software ==
* Ubuntu Linux 11.04 (Natty) [http://www.ubuntu.com/download/ubuntu/download install media] (Other flavors of Ubuntu, including Ubuntu server should work with these instructions as well.)

= Instructions =
== Connect network hardware ==
* Connect one network card to the outside network.
* Connect the other network card to the internal ethernet switch.
* Connect testing computers to the internal network switch.
[[File:Socks_test_setup.2.png|border|600px|SOCKS Testing Network Setup]]

== Install Ubuntu and Packages ==
* Install Ubuntu on the gateway machine. Consult the official Ubuntu install [https://help.ubuntu.com/community/GraphicalInstall instructions] for more information.
* Reboot into the installed system.
* Update the packages on the system.
<bash>
sudo apt-get update
sudo apt-get upgrade
</bash>
* Install some additional useful packages that we will need.
<bash> sudo apt-get install dnsmasq dante-server openssh </bash>
== Configure Network Interfaces ==
* IMPORTANT NOTE: For the purpose of this document, eth0 is the device that is connecting to the outside network, and eth1 is connecting to the internal network. Verify which is which on your setup.
<bash>ifconfig</bash>
Chances are, only one of the ethX devices will have been assigned an IP address by your network, this is the one connected to the external network. If this is not eth0 you need to either switch the network cables connected to the computer or remember to swap the interface names everywhere in the rest of this document. We are going to be assigning eth1 with a static IP address, which can cause problems if it conflicts with the rest of your network.
* Edit, with sudo, '/etc/network/interfaces' and replace its contents with the following
<bash>
auto lo eth0 eth1

iface lo inet loopback

# External network
iface eth0 inet dhcp

# Internal network
iface eth1 inet static
address 192.168.1.1
network 192.168.1.0
netmask 255.255.255.0
broadcast 192.168.1.255
</bash>
* This configuration makes eth0 continue to get its configuration through DHCP, and statically configures eth1. Listing both interfaces on the auto line will mean that they will automatically connect on startup.
* Because we are setting up the interfaces in this config file, we should probably prevent networkmanager from trying to do it as well.
<bash> sudo update-rc.d NetworkManager remove</bash>
* Restart the network
<bash>
sudo /etc/init.d/networking stop
sudo /etc/init.d/networking start
</bash>
* Verify the network configuration by looking for the correct IP addresses for eth0 and eth1.
<bash> ifconfig</bash>

== Set up DNS and DHCP ==
* dnsmasq is a lightweight combination DNS/DHCP server. For the anticipated number of clients for this network, it should be sufficient.
* Warning: Again, it is important to get the network interfaces correct for this. Running a rogue DHCP server on the wrong interface could cause major network problems. eth1 should be the '''internal''' network card.
* Replace /etc/dnsmasq.conf with the following:
<bash>
interface=eth1

dhcp-range=192.168.1.50,192.168.1.150,12h
dhcp-authoritative
dhcp-script=/bin/echo
</bash>
* Restart dnsmasq
<bash> sudo /etc/init.d/dnsmasq restart </bash>

== Set up the Firewall ==
* Save the following two scripts to ~/scripts
=== nat_forward_all.sh ===
<bash>
echo -e "\n\nLoading simple rc.firewall-iptables version $FWVER..\n"
DEPMOD=/sbin/depmod
MODPROBE=/sbin/modprobe

EXTIF="eth0"
INTIF="eth1"
echo " External Interface: $EXTIF"
echo " Internal Interface: $INTIF"

#======================================================================
#== No editing beyond this line is required for initial MASQ testing ==
echo -en " loading modules: "
echo " - Verifying that all kernel modules are ok"
$DEPMOD -a
echo "----------------------------------------------------------------------"
echo -en "ip_tables, "
$MODPROBE ip_tables
echo -en "nf_conntrack, "
$MODPROBE nf_conntrack
echo -en "nf_conntrack_ftp, "
$MODPROBE nf_conntrack_ftp
echo -en "nf_conntrack_irc, "
$MODPROBE nf_conntrack_irc
echo -en "iptable_nat, "
$MODPROBE iptable_nat
echo -en "nf_nat_ftp, "
$MODPROBE nf_nat_ftp
echo "----------------------------------------------------------------------"
echo -e " Done loading modules.\n"
echo " Enabling forwarding.."
echo "1" > /proc/sys/net/ipv4/ip_forward
echo " Enabling DynamicAddr.."
echo "1" > /proc/sys/net/ipv4/ip_dynaddr
echo " Clearing any existing rules and setting default policy.."

iptables-restore <<-EOF
*nat
-A POSTROUTING -o "$EXTIF" -j MASQUERADE
COMMIT
*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A FORWARD -i "$EXTIF" -o "$INTIF" -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -i "$INTIF" -o "$EXTIF" -j ACCEPT
-A FORWARD -j LOG
COMMIT
EOF

echo -e "\nrc.firewall-iptables v$FWVER done.\n"
</bash>
=== nat_block_all.sh ===
<bash>
echo -e "\n\nLoading simple rc.firewall-iptables version $FWVER..\n"
DEPMOD=/sbin/depmod
MODPROBE=/sbin/modprobe

EXTIF="eth0"
INTIF="eth1"
echo " External Interface: $EXTIF"
echo " Internal Interface: $INTIF"

#======================================================================
#== No editing beyond this line is required for initial MASQ testing ==
echo -en " loading modules: "
echo " - Verifying that all kernel modules are ok"
$DEPMOD -a
echo "----------------------------------------------------------------------"
echo -en "ip_tables, "
$MODPROBE ip_tables
echo -en "nf_conntrack, "
$MODPROBE nf_conntrack
echo -en "nf_conntrack_ftp, "
$MODPROBE nf_conntrack_ftp
echo -en "iptable_nat, "
$MODPROBE iptable_nat
echo -en "nf_nat_ftp, "
$MODPROBE nf_nat_ftp
echo "----------------------------------------------------------------------"
echo -e " Done loading modules.\n"
echo " Enabling forwarding.."
echo "1" > /proc/sys/net/ipv4/ip_forward
echo " Enabling DynamicAddr.."
echo "1" > /proc/sys/net/ipv4/ip_dynaddr
echo " Clearing any existing rules and setting default policy.."

iptables-restore <<-EOF
*nat
-A POSTROUTING -o "$EXTIF" -j MASQUERADE
COMMIT
*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A FORWARD -i "$INTIF" -j LOG
-A FORWARD -i "$INTIF" -j REJECT
COMMIT
EOF

echo -e "\nrc.firewall-iptables v$FWVER done.\n"
</bash>
* Make both scripts executable
<bash>
chmod a+x ~/scripts/nat_block_all.sh
chmod a+x ~/scripts/nat_forward_all.sh
</bash>
* Test the wide-open script. Inspect the output for errors indicating something is wrong.
<bash>
sudo ~/scripts/nat_forward_all.sh
</bash>
* If the previous command was successful and you got dns and dhcp configured before, you should be able to connect through your gateway on computers on the internal network.
* Test this now, by connecting a test computer to the network if you haven't already. Try browsing the web on one of the test machines as a quick test. Use '''ipconfig /all''' or '''ifconfig''' to see how the test computer is being configured. Expected values are below: 
{| class="lltable" border="1"
|+ '''Test Machine Network Parameters'''

|--
!Parameter
!Expected Value

|--
| IP Address
| 192.168.1.50-192.168.1.150

|--
| Subnet Mask
| 255.255.255.0

|--
| Default Gateway
| 192.168.1.1

|--
| Nameserver (DNS Server)
| 192.168.1.1

|}

* If everything seems to be working correctly, make the wide-open config run during system startup.
<bash>
sudo cp nat_forward_all.sh /etc/init.d/nat.sh
sudo ln -s /etc/init.d/nat.sh /etc/rc2.d/S95masquradescript
</bash>

== Set up the SOCKS 5 proxy==
* Replace /etc/danted.conf with the following.
<pre>
logoutput: /var/log/dante.log

internal: eth1 port = 1080

external: eth0

method: username none
#the above puts no username or password. Access will instead be controlled via client ip address/range.
#if there is no username or password - then danted socks server needs to run as nobody, i.e.

#user.privileged: proxy
user.notprivileged: nobody

### "client-rules" ###

client pass {
from: 192.168.1.0/16 port 1-65535 to: 0.0.0.0/0
}

client block {
from: 0.0.0.0/0 to: 0.0.0.0/0
log: connect error
}

### "socks-rules" ###
# Block connections to loopback interfaces
block {
from: 0.0.0.0/0 to: 127.0.0.0/8
log: connect error
}

# Allow udp reply packets from outside
pass {
from: 0.0.0.0/0 to: 192.168.1.0/16
command: udpreply
}

# Allow the internal network to connect to everything outside
pass {
from: 192.168.1.0/16 to: 0.0.0.0/0
protocol: tcp udp
}

# Block anything else
block {
from: 0.0.0.0/0 to: 0.0.0.0/0
log: connect error
}

</pre>
* Start the proxy server
<bash> sudo /etc/init.d/danted restart </bash>
* If you get a "Failed to open libc.so..." error message when starting the proxy server, this is caused by a [https://bugs.launchpad.net/ubuntu/+source/dante/+bug/767085 mistake] in the dante-server debian package. To work around this, create a simlink to the correct libc.so and try to start danted again.
<bash> sudo ln -sf /lib/i386-linux-gnu/libc-2.13.so /lib/i386-linux-gnu/libc.so </bash>
* Test connecting through the proxy by configuring the web browser on one of the test machines connected through the gateway to use the proxy.
* Restrict outgoing traffic through the gateway by enabling the more restrictive iptables configuration.
<bash> sudo ~/scripts/nat_block_all.sh </bash>
* In the proxy options section of the browser, supply 192.168.1.1 as the SOCKS server and 1080 as the port.
* Attempt to browse to an internet website. If you can browse as usual, the proxy is working correctly.
* Disable the proxy in the browser.

== Set up the HTTP (Web) proxy ==
=== Configure the HTTP proxy ===
* Edit /etc/squid/squid.conf. We will be editing the existing file instead of replacing it.
* Look for the following line:
http_port 3128
* Replace with the following:
http_port 192.168.1.1:3128
cache
* Look for the following lines:
acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network

* Replace with
acl localnet src 192.168.1.0/8 # RFC1918 possible internal network

* Look for the following line:
acl CONNECT method CONNECT
* Append two lines to make it be:
acl CONNECT method CONNECT
# Enable SSL via CONNECT
acl SSL method CONNECT

* Look for the following line:
http_access allow localhost
* Append another line after it so that it now looks like this:
http_access allow localhost
http_access allow localnet

* A patch to do the above:
<diff>
--- squid.conf.original 2011-07-11 13:58:12.640564821 -0400
+++ squid.conf 2011-07-13 18:44:17.324652415 -0400
@@ -606,8 +606,6 @@
# Example rule allowing access from your local networks.
# Adapt to list your (internal) IP networks from where browsing
# should be allowed
-acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
-acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
#
acl SSL_ports port 443 # https
@@ -628,6 +626,8 @@
acl Safe_ports port 901 # SWAT
acl purge method PURGE
acl CONNECT method CONNECT
+# Enable SSL via CONNECT
+acl SSL method CONNECT

# TAG: http_access
# Allowing or Denying access based on defined access lists
@@ -675,6 +675,8 @@
# from where browsing should be allowed
#http_access allow localnet
http_access allow localhost
+http_access allow localnet
+

# And finally deny all other access to this proxy
http_access deny all
@@ -1111,8 +1113,9 @@
# visible on the internal address.
#
# Squid normally listens to port 3128
-http_port 3128
+http_port 192.168.1.1:3128

+cache deny all
# TAG: https_port
# Note: This option is only available if Squid is rebuilt with the
# --enable-ssl option
</diff>

* Restart the squid proxy:
<bash>
sudo stop squid
sudo start squid
</bash>
* Examine syslog for any errors
<bash>
sudo tail /var/log/syslog
</bash>
=== Test the HTTP Proxy ===
* Restrict outgoing traffic through the gateway by enabling the more restrictive iptables configuration.
<bash> sudo ~/scripts/nat_block_all.sh </bash>
* In the proxy options section of the browser on the test machine, supply 192.168.1.1 as the HTTP and HTTPS proxy server with 3128 as the port in both cases.
* Remove any SOCKS proxy configuration in the browser.
* Attempt to browse to an internet website. Also try browsing to an https:// website such as [https://codereview.secondlife.com https://codereview.secondlife.com]. If you can browse as usual, the proxy is working correctly.
* Disable the proxy in the browser.

== Cleanup ==
* Reboot the machine, using the graphical menus to reboot or the following command. Verify that everything still works as before.
<bash> sudo shutdown -r now </bash>
* Note that we left the unrestricted firewall configuration as the default. When the gateway is rebooted, you will need to rerun '''~/scripts/nat_blocked_all.sh''' to restrict connections again. If you would like that to be the default state, copy '''~/scripts/nat_blocked_all.sh''' to '''/etc/init.d/nat.sh'''.

= Useful References =
If you run into difficulties with these instructions, there is more information in the official documentation. I based the configurations in this document mostly from the following sites:
*[https://help.ubuntu.com/community/Router Ubuntu Router Instructions]

User:Log Linden/Socks5Viewer/TestPlan/ProxyGateway

2011-07-14T14:17:51Z

Log Linden: /* Set up the HTTP (Web) proxy */

= Introduction =
These instructions will help you set up a simple Ubuntu gateway machine that will allow you to control access to the outside network for computers that are operating behind the gateway. This setup was created for testing the SOCKS 5 proxy. With some modification, the same setup could be used for testing various other network conditions, including throttling the connection speed down to something closer to residential DSL speeds. The instructions are intended for someone with a reasonable familiarity with Ubuntu Linux and will only discuss the customisations needed to set up the gateway.

= Requirements =
== Hardware ==
* A standard off-the-shelf PC with two Ethernet NICs
* 1 Ethernet switch for the "internal" network
* Network cables
* Other computers to actually test the viewer on.

== Software ==
* Ubuntu Linux 11.04 (Natty) [http://www.ubuntu.com/download/ubuntu/download install media] (Other flavors of Ubuntu, including Ubuntu server should work with these instructions as well.)

= Instructions =
== Connect network hardware ==
* Connect one network card to the outside network.
* Connect the other network card to the internal ethernet switch.
* Connect testing computers to the internal network switch.
[[File:Socks_test_setup.2.png|border|600px|SOCKS Testing Network Setup]]

== Install Ubuntu and Packages ==
* Install Ubuntu on the gateway machine. Consult the official Ubuntu install [https://help.ubuntu.com/community/GraphicalInstall instructions] for more information.
* Reboot into the installed system.
* Update the packages on the system.
<bash>
sudo apt-get update
sudo apt-get upgrade
</bash>
* Install some additional useful packages that we will need.
<bash> sudo apt-get install dnsmasq dante-server openssh </bash>
== Configure Network Interfaces ==
* IMPORTANT NOTE: For the purpose of this document, eth0 is the device that is connecting to the outside network, and eth1 is connecting to the internal network. Verify which is which on your setup.
<bash>ifconfig</bash>
Chances are, only one of the ethX devices will have been assigned an IP address by your network, this is the one connected to the external network. If this is not eth0 you need to either switch the network cables connected to the computer or remember to swap the interface names everywhere in the rest of this document. We are going to be assigning eth1 with a static IP address, which can cause problems if it conflicts with the rest of your network.
* Edit, with sudo, '/etc/network/interfaces' and replace its contents with the following
<bash>
auto lo eth0 eth1

iface lo inet loopback

# External network
iface eth0 inet dhcp

# Internal network
iface eth1 inet static
address 192.168.1.1
network 192.168.1.0
netmask 255.255.255.0
broadcast 192.168.1.255
</bash>
* This configuration makes eth0 continue to get its configuration through DHCP, and statically configures eth1. Listing both interfaces on the auto line will mean that they will automatically connect on startup.
* Because we are setting up the interfaces in this config file, we should probably prevent networkmanager from trying to do it as well.
<bash> sudo update-rc.d NetworkManager remove</bash>
* Restart the network
<bash>
sudo /etc/init.d/networking stop
sudo /etc/init.d/networking start
</bash>
* Verify the network configuration by looking for the correct IP addresses for eth0 and eth1.
<bash> ifconfig</bash>

== Set up DNS and DHCP ==
* dnsmasq is a lightweight combination DNS/DHCP server. For the anticipated number of clients for this network, it should be sufficient.
* Warning: Again, it is important to get the network interfaces correct for this. Running a rogue DHCP server on the wrong interface could cause major network problems. eth1 should be the '''internal''' network card.
* Replace /etc/dnsmasq.conf with the following:
<bash>
interface=eth1

dhcp-range=192.168.1.50,192.168.1.150,12h
dhcp-authoritative
dhcp-script=/bin/echo
</bash>
* Restart dnsmasq
<bash> sudo /etc/init.d/dnsmasq restart </bash>

== Set up the Firewall ==
* Save the following two scripts to ~/scripts
=== nat_forward_all.sh ===
<bash>
echo -e "\n\nLoading simple rc.firewall-iptables version $FWVER..\n"
DEPMOD=/sbin/depmod
MODPROBE=/sbin/modprobe

EXTIF="eth0"
INTIF="eth1"
echo " External Interface: $EXTIF"
echo " Internal Interface: $INTIF"

#======================================================================
#== No editing beyond this line is required for initial MASQ testing ==
echo -en " loading modules: "
echo " - Verifying that all kernel modules are ok"
$DEPMOD -a
echo "----------------------------------------------------------------------"
echo -en "ip_tables, "
$MODPROBE ip_tables
echo -en "nf_conntrack, "
$MODPROBE nf_conntrack
echo -en "nf_conntrack_ftp, "
$MODPROBE nf_conntrack_ftp
echo -en "nf_conntrack_irc, "
$MODPROBE nf_conntrack_irc
echo -en "iptable_nat, "
$MODPROBE iptable_nat
echo -en "nf_nat_ftp, "
$MODPROBE nf_nat_ftp
echo "----------------------------------------------------------------------"
echo -e " Done loading modules.\n"
echo " Enabling forwarding.."
echo "1" > /proc/sys/net/ipv4/ip_forward
echo " Enabling DynamicAddr.."
echo "1" > /proc/sys/net/ipv4/ip_dynaddr
echo " Clearing any existing rules and setting default policy.."

iptables-restore <<-EOF
*nat
-A POSTROUTING -o "$EXTIF" -j MASQUERADE
COMMIT
*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A FORWARD -i "$EXTIF" -o "$INTIF" -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -i "$INTIF" -o "$EXTIF" -j ACCEPT
-A FORWARD -j LOG
COMMIT
EOF

echo -e "\nrc.firewall-iptables v$FWVER done.\n"
</bash>
=== nat_block_all.sh ===
<bash>
echo -e "\n\nLoading simple rc.firewall-iptables version $FWVER..\n"
DEPMOD=/sbin/depmod
MODPROBE=/sbin/modprobe

EXTIF="eth0"
INTIF="eth1"
echo " External Interface: $EXTIF"
echo " Internal Interface: $INTIF"

#======================================================================
#== No editing beyond this line is required for initial MASQ testing ==
echo -en " loading modules: "
echo " - Verifying that all kernel modules are ok"
$DEPMOD -a
echo "----------------------------------------------------------------------"
echo -en "ip_tables, "
$MODPROBE ip_tables
echo -en "nf_conntrack, "
$MODPROBE nf_conntrack
echo -en "nf_conntrack_ftp, "
$MODPROBE nf_conntrack_ftp
echo -en "iptable_nat, "
$MODPROBE iptable_nat
echo -en "nf_nat_ftp, "
$MODPROBE nf_nat_ftp
echo "----------------------------------------------------------------------"
echo -e " Done loading modules.\n"
echo " Enabling forwarding.."
echo "1" > /proc/sys/net/ipv4/ip_forward
echo " Enabling DynamicAddr.."
echo "1" > /proc/sys/net/ipv4/ip_dynaddr
echo " Clearing any existing rules and setting default policy.."

iptables-restore <<-EOF
*nat
-A POSTROUTING -o "$EXTIF" -j MASQUERADE
COMMIT
*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A FORWARD -i "$INTIF" -j LOG
-A FORWARD -i "$INTIF" -j REJECT
COMMIT
EOF

echo -e "\nrc.firewall-iptables v$FWVER done.\n"
</bash>
* Make both scripts executable
<bash>
chmod a+x ~/scripts/nat_block_all.sh
chmod a+x ~/scripts/nat_forward_all.sh
</bash>
* Test the wide-open script. Inspect the output for errors indicating something is wrong.
<bash>
sudo ~/scripts/nat_forward_all.sh
</bash>
* If the previous command was successful and you got dns and dhcp configured before, you should be able to connect through your gateway on computers on the internal network.
* Test this now, by connecting a test computer to the network if you haven't already. Try browsing the web on one of the test machines as a quick test. Use '''ipconfig /all''' or '''ifconfig''' to see how the test computer is being configured. Expected values are below: 
{| class="lltable" border="1"
|+ '''Test Machine Network Parameters'''

|--
!Parameter
!Expected Value

|--
| IP Address
| 192.168.1.50-192.168.1.150

|--
| Subnet Mask
| 255.255.255.0

|--
| Default Gateway
| 192.168.1.1

|--
| Nameserver (DNS Server)
| 192.168.1.1

|}

* If everything seems to be working correctly, make the wide-open config run during system startup.
<bash>
sudo cp nat_forward_all.sh /etc/init.d/nat.sh
sudo ln -s /etc/init.d/nat.sh /etc/rc2.d/S95masquradescript
</bash>

== Set up the SOCKS 5 proxy==
* Replace /etc/danted.conf with the following.
<pre>
#logoutput: stderr
logoutput: syslog
#the above line will send any logs to /var/log/syslog instead to a terminal

internal: eth1 port = 1080

external: eth0

method: username none
#the above puts no username or password. Access will instead be controlled via client ip address/range.
#if there is no username or password - then danted socks server needs to run as nobody, i.e.

#user.privileged: proxy
user.notprivileged: nobody

### "client-rules" ###
#client pass {
# from: 136.201.251.21/0 port 1-65535 to: 0.0.0.0/0
# # 136.201.251.21/0 = specific ip address.
# }

client pass {
from: 192.168.1.0/16 port 1-65535 to: 0.0.0.0/0
}

client block {
from: 0.0.0.0/0 to: 0.0.0.0/0
log: connect error
}

### "socks-rules" ###
block {
from: 0.0.0.0/0 to: 127.0.0.0/8
log: connect error
}

pass {
from: 192.168.1.0/16 to: 0.0.0.0/0
protocol: tcp udp
}

pass {
from: 127.0.0.0/8 to: 0.0.0.0/0
protocol: tcp udp
}

block {
from: 0.0.0.0/0 to: 0.0.0.0/0
log: connect error
}
</pre>
* Start the proxy server
<bash> sudo /etc/init.d/danted restart </bash>
* If you get a "Failed to open libc.so..." error message when starting the proxy server, this is caused by a [https://bugs.launchpad.net/ubuntu/+source/dante/+bug/767085 mistake] in the dante-server debian package. To work around this, create a simlink to the correct libc.so and try to start danted again.
<bash> sudo ln -sf /lib/i386-linux-gnu/libc-2.13.so /lib/i386-linux-gnu/libc.so </bash>
* Test connecting through the proxy by configuring the web browser on one of the test machines connected through the gateway to use the proxy.
* Restrict outgoing traffic through the gateway by enabling the more restrictive iptables configuration.
<bash> sudo ~/scripts/nat_block_all.sh </bash>
* In the proxy options section of the browser, supply 192.168.1.1 as the SOCKS server and 1080 as the port.
* Attempt to browse to an internet website. If you can browse as usual, the proxy is working correctly.
* Disable the proxy in the browser.

== Set up the HTTP (Web) proxy ==
=== Configure the HTTP proxy ===
* Edit /etc/squid/squid.conf. We will be editing the existing file instead of replacing it.
* Look for the following line:
http_port 3128
* Replace with the following:
http_port 192.168.1.1:3128
cache
* Look for the following lines:
acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network

* Replace with
acl localnet src 192.168.1.0/8 # RFC1918 possible internal network

* Look for the following line:
acl CONNECT method CONNECT
* Append two lines to make it be:
acl CONNECT method CONNECT
# Enable SSL via CONNECT
acl SSL method CONNECT

* Look for the following line:
http_access allow localhost
* Append another line after it so that it now looks like this:
http_access allow localhost
http_access allow localnet

* A patch to do the above:
<diff>
--- squid.conf.original 2011-07-11 13:58:12.640564821 -0400
+++ squid.conf 2011-07-13 18:44:17.324652415 -0400
@@ -606,8 +606,6 @@
# Example rule allowing access from your local networks.
# Adapt to list your (internal) IP networks from where browsing
# should be allowed
-acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
-acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
#
acl SSL_ports port 443 # https
@@ -628,6 +626,8 @@
acl Safe_ports port 901 # SWAT
acl purge method PURGE
acl CONNECT method CONNECT
+# Enable SSL via CONNECT
+acl SSL method CONNECT

# TAG: http_access
# Allowing or Denying access based on defined access lists
@@ -675,6 +675,8 @@
# from where browsing should be allowed
#http_access allow localnet
http_access allow localhost
+http_access allow localnet
+

# And finally deny all other access to this proxy
http_access deny all
@@ -1111,8 +1113,9 @@
# visible on the internal address.
#
# Squid normally listens to port 3128
-http_port 3128
+http_port 192.168.1.1:3128

+cache deny all
# TAG: https_port
# Note: This option is only available if Squid is rebuilt with the
# --enable-ssl option
</diff>

* Restart the squid proxy:
<bash>
sudo stop squid
sudo start squid
</bash>
* Examine syslog for any errors
<bash>
sudo tail /var/log/syslog
</bash>
=== Test the HTTP Proxy ===
* Restrict outgoing traffic through the gateway by enabling the more restrictive iptables configuration.
<bash> sudo ~/scripts/nat_block_all.sh </bash>
* In the proxy options section of the browser on the test machine, supply 192.168.1.1 as the HTTP and HTTPS proxy server with 3128 as the port in both cases.
* Remove any SOCKS proxy configuration in the browser.
* Attempt to browse to an internet website. Also try browsing to an https:// website such as [https://codereview.secondlife.com https://codereview.secondlife.com]. If you can browse as usual, the proxy is working correctly.
* Disable the proxy in the browser.

== Cleanup ==
* Reboot the machine, using the graphical menus to reboot or the following command. Verify that everything still works as before.
<bash> sudo shutdown -r now </bash>
* Note that we left the unrestricted firewall configuration as the default. When the gateway is rebooted, you will need to rerun '''~/scripts/nat_blocked_all.sh''' to restrict connections again. If you would like that to be the default state, copy '''~/scripts/nat_blocked_all.sh''' to '''/etc/init.d/nat.sh'''.

= Useful References =
If you run into difficulties with these instructions, there is more information in the official documentation. I based the configurations in this document mostly from the following sites:
*[https://help.ubuntu.com/community/Router Ubuntu Router Instructions]

User:Log Linden/Socks5Viewer/TestPlan/ProxyGateway

2011-07-14T14:15:45Z

Log Linden: /* Set up the HTTP (Web) proxy */ Changed the proxy configuration to support http through the CONNECT method

= Introduction =
These instructions will help you set up a simple Ubuntu gateway machine that will allow you to control access to the outside network for computers that are operating behind the gateway. This setup was created for testing the SOCKS 5 proxy. With some modification, the same setup could be used for testing various other network conditions, including throttling the connection speed down to something closer to residential DSL speeds. The instructions are intended for someone with a reasonable familiarity with Ubuntu Linux and will only discuss the customisations needed to set up the gateway.

= Requirements =
== Hardware ==
* A standard off-the-shelf PC with two Ethernet NICs
* 1 Ethernet switch for the "internal" network
* Network cables
* Other computers to actually test the viewer on.

== Software ==
* Ubuntu Linux 11.04 (Natty) [http://www.ubuntu.com/download/ubuntu/download install media] (Other flavors of Ubuntu, including Ubuntu server should work with these instructions as well.)

= Instructions =
== Connect network hardware ==
* Connect one network card to the outside network.
* Connect the other network card to the internal ethernet switch.
* Connect testing computers to the internal network switch.
[[File:Socks_test_setup.2.png|border|600px|SOCKS Testing Network Setup]]

== Install Ubuntu and Packages ==
* Install Ubuntu on the gateway machine. Consult the official Ubuntu install [https://help.ubuntu.com/community/GraphicalInstall instructions] for more information.
* Reboot into the installed system.
* Update the packages on the system.
<bash>
sudo apt-get update
sudo apt-get upgrade
</bash>
* Install some additional useful packages that we will need.
<bash> sudo apt-get install dnsmasq dante-server openssh </bash>
== Configure Network Interfaces ==
* IMPORTANT NOTE: For the purpose of this document, eth0 is the device that is connecting to the outside network, and eth1 is connecting to the internal network. Verify which is which on your setup.
<bash>ifconfig</bash>
Chances are, only one of the ethX devices will have been assigned an IP address by your network, this is the one connected to the external network. If this is not eth0 you need to either switch the network cables connected to the computer or remember to swap the interface names everywhere in the rest of this document. We are going to be assigning eth1 with a static IP address, which can cause problems if it conflicts with the rest of your network.
* Edit, with sudo, '/etc/network/interfaces' and replace its contents with the following
<bash>
auto lo eth0 eth1

iface lo inet loopback

# External network
iface eth0 inet dhcp

# Internal network
iface eth1 inet static
address 192.168.1.1
network 192.168.1.0
netmask 255.255.255.0
broadcast 192.168.1.255
</bash>
* This configuration makes eth0 continue to get its configuration through DHCP, and statically configures eth1. Listing both interfaces on the auto line will mean that they will automatically connect on startup.
* Because we are setting up the interfaces in this config file, we should probably prevent networkmanager from trying to do it as well.
<bash> sudo update-rc.d NetworkManager remove</bash>
* Restart the network
<bash>
sudo /etc/init.d/networking stop
sudo /etc/init.d/networking start
</bash>
* Verify the network configuration by looking for the correct IP addresses for eth0 and eth1.
<bash> ifconfig</bash>

== Set up DNS and DHCP ==
* dnsmasq is a lightweight combination DNS/DHCP server. For the anticipated number of clients for this network, it should be sufficient.
* Warning: Again, it is important to get the network interfaces correct for this. Running a rogue DHCP server on the wrong interface could cause major network problems. eth1 should be the '''internal''' network card.
* Replace /etc/dnsmasq.conf with the following:
<bash>
interface=eth1

dhcp-range=192.168.1.50,192.168.1.150,12h
dhcp-authoritative
dhcp-script=/bin/echo
</bash>
* Restart dnsmasq
<bash> sudo /etc/init.d/dnsmasq restart </bash>

== Set up the Firewall ==
* Save the following two scripts to ~/scripts
=== nat_forward_all.sh ===
<bash>
echo -e "\n\nLoading simple rc.firewall-iptables version $FWVER..\n"
DEPMOD=/sbin/depmod
MODPROBE=/sbin/modprobe

EXTIF="eth0"
INTIF="eth1"
echo " External Interface: $EXTIF"
echo " Internal Interface: $INTIF"

#======================================================================
#== No editing beyond this line is required for initial MASQ testing ==
echo -en " loading modules: "
echo " - Verifying that all kernel modules are ok"
$DEPMOD -a
echo "----------------------------------------------------------------------"
echo -en "ip_tables, "
$MODPROBE ip_tables
echo -en "nf_conntrack, "
$MODPROBE nf_conntrack
echo -en "nf_conntrack_ftp, "
$MODPROBE nf_conntrack_ftp
echo -en "nf_conntrack_irc, "
$MODPROBE nf_conntrack_irc
echo -en "iptable_nat, "
$MODPROBE iptable_nat
echo -en "nf_nat_ftp, "
$MODPROBE nf_nat_ftp
echo "----------------------------------------------------------------------"
echo -e " Done loading modules.\n"
echo " Enabling forwarding.."
echo "1" > /proc/sys/net/ipv4/ip_forward
echo " Enabling DynamicAddr.."
echo "1" > /proc/sys/net/ipv4/ip_dynaddr
echo " Clearing any existing rules and setting default policy.."

iptables-restore <<-EOF
*nat
-A POSTROUTING -o "$EXTIF" -j MASQUERADE
COMMIT
*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A FORWARD -i "$EXTIF" -o "$INTIF" -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -i "$INTIF" -o "$EXTIF" -j ACCEPT
-A FORWARD -j LOG
COMMIT
EOF

echo -e "\nrc.firewall-iptables v$FWVER done.\n"
</bash>
=== nat_block_all.sh ===
<bash>
echo -e "\n\nLoading simple rc.firewall-iptables version $FWVER..\n"
DEPMOD=/sbin/depmod
MODPROBE=/sbin/modprobe

EXTIF="eth0"
INTIF="eth1"
echo " External Interface: $EXTIF"
echo " Internal Interface: $INTIF"

#======================================================================
#== No editing beyond this line is required for initial MASQ testing ==
echo -en " loading modules: "
echo " - Verifying that all kernel modules are ok"
$DEPMOD -a
echo "----------------------------------------------------------------------"
echo -en "ip_tables, "
$MODPROBE ip_tables
echo -en "nf_conntrack, "
$MODPROBE nf_conntrack
echo -en "nf_conntrack_ftp, "
$MODPROBE nf_conntrack_ftp
echo -en "iptable_nat, "
$MODPROBE iptable_nat
echo -en "nf_nat_ftp, "
$MODPROBE nf_nat_ftp
echo "----------------------------------------------------------------------"
echo -e " Done loading modules.\n"
echo " Enabling forwarding.."
echo "1" > /proc/sys/net/ipv4/ip_forward
echo " Enabling DynamicAddr.."
echo "1" > /proc/sys/net/ipv4/ip_dynaddr
echo " Clearing any existing rules and setting default policy.."

iptables-restore <<-EOF
*nat
-A POSTROUTING -o "$EXTIF" -j MASQUERADE
COMMIT
*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A FORWARD -i "$INTIF" -j LOG
-A FORWARD -i "$INTIF" -j REJECT
COMMIT
EOF

echo -e "\nrc.firewall-iptables v$FWVER done.\n"
</bash>
* Make both scripts executable
<bash>
chmod a+x ~/scripts/nat_block_all.sh
chmod a+x ~/scripts/nat_forward_all.sh
</bash>
* Test the wide-open script. Inspect the output for errors indicating something is wrong.
<bash>
sudo ~/scripts/nat_forward_all.sh
</bash>
* If the previous command was successful and you got dns and dhcp configured before, you should be able to connect through your gateway on computers on the internal network.
* Test this now, by connecting a test computer to the network if you haven't already. Try browsing the web on one of the test machines as a quick test. Use '''ipconfig /all''' or '''ifconfig''' to see how the test computer is being configured. Expected values are below: 
{| class="lltable" border="1"
|+ '''Test Machine Network Parameters'''

|--
!Parameter
!Expected Value

|--
| IP Address
| 192.168.1.50-192.168.1.150

|--
| Subnet Mask
| 255.255.255.0

|--
| Default Gateway
| 192.168.1.1

|--
| Nameserver (DNS Server)
| 192.168.1.1

|}

* If everything seems to be working correctly, make the wide-open config run during system startup.
<bash>
sudo cp nat_forward_all.sh /etc/init.d/nat.sh
sudo ln -s /etc/init.d/nat.sh /etc/rc2.d/S95masquradescript
</bash>

== Set up the SOCKS 5 proxy==
* Replace /etc/danted.conf with the following.
<pre>
#logoutput: stderr
logoutput: syslog
#the above line will send any logs to /var/log/syslog instead to a terminal

internal: eth1 port = 1080

external: eth0

method: username none
#the above puts no username or password. Access will instead be controlled via client ip address/range.
#if there is no username or password - then danted socks server needs to run as nobody, i.e.

#user.privileged: proxy
user.notprivileged: nobody

### "client-rules" ###
#client pass {
# from: 136.201.251.21/0 port 1-65535 to: 0.0.0.0/0
# # 136.201.251.21/0 = specific ip address.
# }

client pass {
from: 192.168.1.0/16 port 1-65535 to: 0.0.0.0/0
}

client block {
from: 0.0.0.0/0 to: 0.0.0.0/0
log: connect error
}

### "socks-rules" ###
block {
from: 0.0.0.0/0 to: 127.0.0.0/8
log: connect error
}

pass {
from: 192.168.1.0/16 to: 0.0.0.0/0
protocol: tcp udp
}

pass {
from: 127.0.0.0/8 to: 0.0.0.0/0
protocol: tcp udp
}

block {
from: 0.0.0.0/0 to: 0.0.0.0/0
log: connect error
}
</pre>
* Start the proxy server
<bash> sudo /etc/init.d/danted restart </bash>
* If you get a "Failed to open libc.so..." error message when starting the proxy server, this is caused by a [https://bugs.launchpad.net/ubuntu/+source/dante/+bug/767085 mistake] in the dante-server debian package. To work around this, create a simlink to the correct libc.so and try to start danted again.
<bash> sudo ln -sf /lib/i386-linux-gnu/libc-2.13.so /lib/i386-linux-gnu/libc.so </bash>
* Test connecting through the proxy by configuring the web browser on one of the test machines connected through the gateway to use the proxy.
* Restrict outgoing traffic through the gateway by enabling the more restrictive iptables configuration.
<bash> sudo ~/scripts/nat_block_all.sh </bash>
* In the proxy options section of the browser, supply 192.168.1.1 as the SOCKS server and 1080 as the port.
* Attempt to browse to an internet website. If you can browse as usual, the proxy is working correctly.
* Disable the proxy in the browser.

== Set up the HTTP (Web) proxy ==
* Edit /etc/squid/squid.conf. We will be editing the existing file instead of replacing it.
* Look for the following line:
http_port 3128
* Replace with the following:
http_port 192.168.1.1:3128
cache
* Look for the following lines:
acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network

* Replace with
acl localnet src 192.168.1.0/8 # RFC1918 possible internal network

* Look for the following line:
acl CONNECT method CONNECT
* Append two lines to make it be:
acl CONNECT method CONNECT
# Enable SSL via CONNECT
acl SSL method CONNECT

* Look for the following line:
http_access allow localhost
* Append another line after it so that it now looks like this:
http_access allow localhost
http_access allow localnet

* A patch to do the above:
<diff>
--- squid.conf.original 2011-07-11 13:58:12.640564821 -0400
+++ squid.conf 2011-07-13 18:44:17.324652415 -0400
@@ -606,8 +606,6 @@
# Example rule allowing access from your local networks.
# Adapt to list your (internal) IP networks from where browsing
# should be allowed
-acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
-acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
#
acl SSL_ports port 443 # https
@@ -628,6 +626,8 @@
acl Safe_ports port 901 # SWAT
acl purge method PURGE
acl CONNECT method CONNECT
+# Enable SSL via CONNECT
+acl SSL method CONNECT

# TAG: http_access
# Allowing or Denying access based on defined access lists
@@ -675,6 +675,8 @@
# from where browsing should be allowed
#http_access allow localnet
http_access allow localhost
+http_access allow localnet
+

# And finally deny all other access to this proxy
http_access deny all
@@ -1111,8 +1113,9 @@
# visible on the internal address.
#
# Squid normally listens to port 3128
-http_port 3128
+http_port 192.168.1.1:3128

+cache deny all
# TAG: https_port
# Note: This option is only available if Squid is rebuilt with the
# --enable-ssl option
</diff>

* Restart the squid proxy:
<bash>
sudo stop squid
sudo start squid
</bash>
* Examine syslog for any errors
<bash>
sudo tail /var/log/syslog
</bash>
* Try to connect through the http proxy.
* Restrict outgoing traffic through the gateway by enabling the more restrictive iptables configuration.
<bash> sudo ~/scripts/nat_block_all.sh </bash>
* In the proxy options section of the browser, supply 192.168.1.1 as the HTTP and HTTPS proxy server with 3128 as the port in both cases..
* Attempt to browse to an internet website. Also try browsing to an https:// website such as [https://codereview.secondlife.com https://codereview.secondlife.com]. If you can browse as usual, the proxy is working correctly.
* Disable the proxy in the browser.

== Cleanup ==
* Reboot the machine, using the graphical menus to reboot or the following command. Verify that everything still works as before.
<bash> sudo shutdown -r now </bash>
* Note that we left the unrestricted firewall configuration as the default. When the gateway is rebooted, you will need to rerun '''~/scripts/nat_blocked_all.sh''' to restrict connections again. If you would like that to be the default state, copy '''~/scripts/nat_blocked_all.sh''' to '''/etc/init.d/nat.sh'''.

= Useful References =
If you run into difficulties with these instructions, there is more information in the official documentation. I based the configurations in this document mostly from the following sites:
*[https://help.ubuntu.com/community/Router Ubuntu Router Instructions]

User:Log Linden/Socks5Viewer/TestPlan/ProxyGateway

2011-07-11T21:54:39Z

Log Linden: /* Hardware */ wording fix

= Introduction =
These instructions will help you set up a simple Ubuntu gateway machine that will allow you to control access to the outside network for computers that are operating behind the gateway. This setup was created for testing the SOCKS 5 proxy. With some modification, the same setup could be used for testing various other network conditions, including throttling the connection speed down to something closer to residential DSL speeds. The instructions are intended for someone with a reasonable familiarity with Ubuntu Linux and will only discuss the customisations needed to set up the gateway.

= Requirements =
== Hardware ==
* A standard off-the-shelf PC with two Ethernet NICs
* 1 Ethernet switch for the "internal" network
* Network cables
* Other computers to actually test the viewer on.

== Software ==
* Ubuntu Linux 11.04 (Natty) [http://www.ubuntu.com/download/ubuntu/download install media] (Other flavors of Ubuntu, including Ubuntu server should work with these instructions as well.)

= Instructions =
== Connect network hardware ==
* Connect one network card to the outside network.
* Connect the other network card to the internal ethernet switch.
* Connect testing computers to the internal network switch.
[[File:Socks_test_setup.2.png|border|600px|SOCKS Testing Network Setup]]

== Install Ubuntu and Packages ==
* Install Ubuntu on the gateway machine. Consult the official Ubuntu install [https://help.ubuntu.com/community/GraphicalInstall instructions] for more information.
* Reboot into the installed system.
* Update the packages on the system.
<bash>
sudo apt-get update
sudo apt-get upgrade
</bash>
* Install some additional useful packages that we will need.
<bash> sudo apt-get install dnsmasq dante-server openssh </bash>
== Configure Network Interfaces ==
* IMPORTANT NOTE: For the purpose of this document, eth0 is the device that is connecting to the outside network, and eth1 is connecting to the internal network. Verify which is which on your setup.
<bash>ifconfig</bash>
Chances are, only one of the ethX devices will have been assigned an IP address by your network, this is the one connected to the external network. If this is not eth0 you need to either switch the network cables connected to the computer or remember to swap the interface names everywhere in the rest of this document. We are going to be assigning eth1 with a static IP address, which can cause problems if it conflicts with the rest of your network.
* Edit, with sudo, '/etc/network/interfaces' and replace its contents with the following
<bash>
auto lo eth0 eth1

iface lo inet loopback

# External network
iface eth0 inet dhcp

# Internal network
iface eth1 inet static
address 192.168.1.1
network 192.168.1.0
netmask 255.255.255.0
broadcast 192.168.1.255
</bash>
* This configuration makes eth0 continue to get its configuration through DHCP, and statically configures eth1. Listing both interfaces on the auto line will mean that they will automatically connect on startup.
* Because we are setting up the interfaces in this config file, we should probably prevent networkmanager from trying to do it as well.
<bash> sudo update-rc.d NetworkManager remove</bash>
* Restart the network
<bash>
sudo /etc/init.d/networking stop
sudo /etc/init.d/networking start
</bash>
* Verify the network configuration by looking for the correct IP addresses for eth0 and eth1.
<bash> ifconfig</bash>

== Set up DNS and DHCP ==
* dnsmasq is a lightweight combination DNS/DHCP server. For the anticipated number of clients for this network, it should be sufficient.
* Warning: Again, it is important to get the network interfaces correct for this. Running a rogue DHCP server on the wrong interface could cause major network problems. eth1 should be the '''internal''' network card.
* Replace /etc/dnsmasq.conf with the following:
<bash>
interface=eth1

dhcp-range=192.168.1.50,192.168.1.150,12h
dhcp-authoritative
dhcp-script=/bin/echo
</bash>
* Restart dnsmasq
<bash> sudo /etc/init.d/dnsmasq restart </bash>

== Set up the Firewall ==
* Save the following two scripts to ~/scripts
=== nat_forward_all.sh ===
<bash>
echo -e "\n\nLoading simple rc.firewall-iptables version $FWVER..\n"
DEPMOD=/sbin/depmod
MODPROBE=/sbin/modprobe

EXTIF="eth0"
INTIF="eth1"
echo " External Interface: $EXTIF"
echo " Internal Interface: $INTIF"

#======================================================================
#== No editing beyond this line is required for initial MASQ testing ==
echo -en " loading modules: "
echo " - Verifying that all kernel modules are ok"
$DEPMOD -a
echo "----------------------------------------------------------------------"
echo -en "ip_tables, "
$MODPROBE ip_tables
echo -en "nf_conntrack, "
$MODPROBE nf_conntrack
echo -en "nf_conntrack_ftp, "
$MODPROBE nf_conntrack_ftp
echo -en "nf_conntrack_irc, "
$MODPROBE nf_conntrack_irc
echo -en "iptable_nat, "
$MODPROBE iptable_nat
echo -en "nf_nat_ftp, "
$MODPROBE nf_nat_ftp
echo "----------------------------------------------------------------------"
echo -e " Done loading modules.\n"
echo " Enabling forwarding.."
echo "1" > /proc/sys/net/ipv4/ip_forward
echo " Enabling DynamicAddr.."
echo "1" > /proc/sys/net/ipv4/ip_dynaddr
echo " Clearing any existing rules and setting default policy.."

iptables-restore <<-EOF
*nat
-A POSTROUTING -o "$EXTIF" -j MASQUERADE
COMMIT
*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A FORWARD -i "$EXTIF" -o "$INTIF" -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -i "$INTIF" -o "$EXTIF" -j ACCEPT
-A FORWARD -j LOG
COMMIT
EOF

echo -e "\nrc.firewall-iptables v$FWVER done.\n"
</bash>
=== nat_block_all.sh ===
<bash>
echo -e "\n\nLoading simple rc.firewall-iptables version $FWVER..\n"
DEPMOD=/sbin/depmod
MODPROBE=/sbin/modprobe

EXTIF="eth0"
INTIF="eth1"
echo " External Interface: $EXTIF"
echo " Internal Interface: $INTIF"

#======================================================================
#== No editing beyond this line is required for initial MASQ testing ==
echo -en " loading modules: "
echo " - Verifying that all kernel modules are ok"
$DEPMOD -a
echo "----------------------------------------------------------------------"
echo -en "ip_tables, "
$MODPROBE ip_tables
echo -en "nf_conntrack, "
$MODPROBE nf_conntrack
echo -en "nf_conntrack_ftp, "
$MODPROBE nf_conntrack_ftp
echo -en "iptable_nat, "
$MODPROBE iptable_nat
echo -en "nf_nat_ftp, "
$MODPROBE nf_nat_ftp
echo "----------------------------------------------------------------------"
echo -e " Done loading modules.\n"
echo " Enabling forwarding.."
echo "1" > /proc/sys/net/ipv4/ip_forward
echo " Enabling DynamicAddr.."
echo "1" > /proc/sys/net/ipv4/ip_dynaddr
echo " Clearing any existing rules and setting default policy.."

iptables-restore <<-EOF
*nat
-A POSTROUTING -o "$EXTIF" -j MASQUERADE
COMMIT
*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A FORWARD -i "$INTIF" -j LOG
-A FORWARD -i "$INTIF" -j REJECT
COMMIT
EOF

echo -e "\nrc.firewall-iptables v$FWVER done.\n"
</bash>
* Make both scripts executable
<bash>
chmod a+x ~/scripts/nat_block_all.sh
chmod a+x ~/scripts/nat_forward_all.sh
</bash>
* Test the wide-open script. Inspect the output for errors indicating something is wrong.
<bash>
sudo ~/scripts/nat_forward_all.sh
</bash>
* If the previous command was successful and you got dns and dhcp configured before, you should be able to connect through your gateway on computers on the internal network.
* Test this now, by connecting a test computer to the network if you haven't already. Try browsing the web on one of the test machines as a quick test. Use '''ipconfig /all''' or '''ifconfig''' to see how the test computer is being configured. Expected values are below: 
{| class="lltable" border="1"
|+ '''Test Machine Network Parameters'''

|--
!Parameter
!Expected Value

|--
| IP Address
| 192.168.1.50-192.168.1.150

|--
| Subnet Mask
| 255.255.255.0

|--
| Default Gateway
| 192.168.1.1

|--
| Nameserver (DNS Server)
| 192.168.1.1

|}

* If everything seems to be working correctly, make the wide-open config run during system startup.
<bash>
sudo cp nat_forward_all.sh /etc/init.d/nat.sh
sudo ln -s /etc/init.d/nat.sh /etc/rc2.d/S95masquradescript
</bash>

== Set up the SOCKS 5 proxy==
* Replace /etc/danted.conf with the following.
<pre>
#logoutput: stderr
logoutput: syslog
#the above line will send any logs to /var/log/syslog instead to a terminal

internal: eth1 port = 1080

external: eth0

method: username none
#the above puts no username or password. Access will instead be controlled via client ip address/range.
#if there is no username or password - then danted socks server needs to run as nobody, i.e.

#user.privileged: proxy
user.notprivileged: nobody

### "client-rules" ###
#client pass {
# from: 136.201.251.21/0 port 1-65535 to: 0.0.0.0/0
# # 136.201.251.21/0 = specific ip address.
# }

client pass {
from: 192.168.1.0/16 port 1-65535 to: 0.0.0.0/0
}

client block {
from: 0.0.0.0/0 to: 0.0.0.0/0
log: connect error
}

### "socks-rules" ###
block {
from: 0.0.0.0/0 to: 127.0.0.0/8
log: connect error
}

pass {
from: 192.168.1.0/16 to: 0.0.0.0/0
protocol: tcp udp
}

pass {
from: 127.0.0.0/8 to: 0.0.0.0/0
protocol: tcp udp
}

block {
from: 0.0.0.0/0 to: 0.0.0.0/0
log: connect error
}
</pre>
* Start the proxy server
<bash> sudo /etc/init.d/danted restart </bash>
* If you get a "Failed to open libc.so..." error message when starting the proxy server, this is caused by a [https://bugs.launchpad.net/ubuntu/+source/dante/+bug/767085 mistake] in the dante-server debian package. To work around this, create a simlink to the correct libc.so and try to start danted again.
<bash> sudo ln -sf /lib/i386-linux-gnu/libc-2.13.so /lib/i386-linux-gnu/libc.so </bash>
* Test connecting through the proxy by configuring the web browser on one of the test machines connected through the gateway to use the proxy.
* Restrict outgoing traffic through the gateway by enabling the more restrictive iptables configuration.
<bash> sudo ~/scripts/nat_block_all.sh </bash>
* In the proxy options section of the browser, supply 192.168.1.1 as the SOCKS server and 1080 as the port.
* Attempt to browse to an internet website. If you can browse as usual, the proxy is working correctly.
* Disable the proxy in the browser.

== Set up the HTTP (Web) proxy ==
* Edit /etc/squid/squid.conf. We will be editing the existing file instead of replacing it.
* Look for the following line:
http_port 3128
* Replace with the following:
http_port 192.168.1.1:3128
cache
* Look for the following lines:
acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network

* Replace with
acl localnet src 192.168.1.0/8 # RFC1918 possible internal network

* Look for the following line:
http_access allow localhost
* Append another line after it so that it now looks like this:
http_access allow localhost
http_access allow localnet

* A patch to do the above:
<diff>
--- squid.conf.original 2011-07-11 13:58:12.640564821 -0400
+++ squid.conf 2011-07-11 14:37:18.640566228 -0400
@@ -606,9 +606,7 @@
# Example rule allowing access from your local networks.
# Adapt to list your (internal) IP networks from where browsing
# should be allowed
-acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
-acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
-acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
+acl localnet src 192.168.1.0/8 # RFC1918 possible internal network
#
acl SSL_ports port 443 # https
acl SSL_ports port 563 # snews
@@ -675,6 +673,8 @@
# from where browsing should be allowed
#http_access allow localnet
http_access allow localhost
+http_access allow localnet
+

# And finally deny all other access to this proxy
http_access deny all
@@ -1111,8 +1111,9 @@
# visible on the internal address.
#
# Squid normally listens to port 3128
-http_port 3128
+http_port 192.168.1.1:3128

+cache deny all
# TAG: https_port
# Note: This option is only available if Squid is rebuilt with the
# --enable-ssl option
</diff>

* Restart the squid proxy:
<bash>
sudo stop squid
sudo start squid
</bash>
* Examine syslog for any errors
<bash>
sudo tail /var/log/syslog
</bash>
* Try to connect through the http proxy.
* In the proxy options section of the browser, supply 192.168.1.1 as thettings in a web browser on the test machine that is behind the firewall.
* Restrict outgoing traffic through the gateway by enabling the more restrictive iptables configuration.
<bash> sudo ~/scripts/nat_block_all.sh </bash>
* In the proxy options section of the browser, supply 192.168.1.1 as the HTTP proxy server and 3128 as the port.
* Attempt to browse to an internet website. If you can browse as usual, the proxy is working correctly.
* Disable the proxy in the browser.

== Cleanup ==
* Reboot the machine, using the graphical menus to reboot or the following command. Verify that everything still works as before.
<bash> sudo shutdown -r now </bash>
* Note that we left the unrestricted firewall configuration as the default. When the gateway is rebooted, you will need to rerun '''~/scripts/nat_blocked_all.sh''' to restrict connections again. If you would like that to be the default state, copy '''~/scripts/nat_blocked_all.sh''' to '''/etc/init.d/nat.sh'''.

= Useful References =
If you run into difficulties with these instructions, there is more information in the official documentation. I based the configurations in this document mostly from the following sites:
*[https://help.ubuntu.com/community/Router Ubuntu Router Instructions]

User:Log Linden/Socks5Viewer/TestPlan/ProxyGateway

2011-07-11T21:53:33Z

Log Linden: /* Connect network hardware */

= Introduction =
These instructions will help you set up a simple Ubuntu gateway machine that will allow you to control access to the outside network for computers that are operating behind the gateway. This setup was created for testing the SOCKS 5 proxy. With some modification, the same setup could be used for testing various other network conditions, including throttling the connection speed down to something closer to residential DSL speeds. The instructions are intended for someone with a reasonable familiarity with Ubuntu Linux and will only discuss the customisations needed to set up the gateway.

= Requirements =
== Hardware ==
* A standard off-the-shelf PC with two Ethernet NICs
* 1 Ethernet switch for the "internal" network
* Network cables
* Other computers to actually run the viewer on.
== Software ==
* Ubuntu Linux 11.04 (Natty) [http://www.ubuntu.com/download/ubuntu/download install media] (Other flavors of Ubuntu, including Ubuntu server should work with these instructions as well.)

= Instructions =
== Connect network hardware ==
* Connect one network card to the outside network.
* Connect the other network card to the internal ethernet switch.
* Connect testing computers to the internal network switch.
[[File:Socks_test_setup.2.png|border|600px|SOCKS Testing Network Setup]]

== Install Ubuntu and Packages ==
* Install Ubuntu on the gateway machine. Consult the official Ubuntu install [https://help.ubuntu.com/community/GraphicalInstall instructions] for more information.
* Reboot into the installed system.
* Update the packages on the system.
<bash>
sudo apt-get update
sudo apt-get upgrade
</bash>
* Install some additional useful packages that we will need.
<bash> sudo apt-get install dnsmasq dante-server openssh </bash>
== Configure Network Interfaces ==
* IMPORTANT NOTE: For the purpose of this document, eth0 is the device that is connecting to the outside network, and eth1 is connecting to the internal network. Verify which is which on your setup.
<bash>ifconfig</bash>
Chances are, only one of the ethX devices will have been assigned an IP address by your network, this is the one connected to the external network. If this is not eth0 you need to either switch the network cables connected to the computer or remember to swap the interface names everywhere in the rest of this document. We are going to be assigning eth1 with a static IP address, which can cause problems if it conflicts with the rest of your network.
* Edit, with sudo, '/etc/network/interfaces' and replace its contents with the following
<bash>
auto lo eth0 eth1

iface lo inet loopback

# External network
iface eth0 inet dhcp

# Internal network
iface eth1 inet static
address 192.168.1.1
network 192.168.1.0
netmask 255.255.255.0
broadcast 192.168.1.255
</bash>
* This configuration makes eth0 continue to get its configuration through DHCP, and statically configures eth1. Listing both interfaces on the auto line will mean that they will automatically connect on startup.
* Because we are setting up the interfaces in this config file, we should probably prevent networkmanager from trying to do it as well.
<bash> sudo update-rc.d NetworkManager remove</bash>
* Restart the network
<bash>
sudo /etc/init.d/networking stop
sudo /etc/init.d/networking start
</bash>
* Verify the network configuration by looking for the correct IP addresses for eth0 and eth1.
<bash> ifconfig</bash>

== Set up DNS and DHCP ==
* dnsmasq is a lightweight combination DNS/DHCP server. For the anticipated number of clients for this network, it should be sufficient.
* Warning: Again, it is important to get the network interfaces correct for this. Running a rogue DHCP server on the wrong interface could cause major network problems. eth1 should be the '''internal''' network card.
* Replace /etc/dnsmasq.conf with the following:
<bash>
interface=eth1

dhcp-range=192.168.1.50,192.168.1.150,12h
dhcp-authoritative
dhcp-script=/bin/echo
</bash>
* Restart dnsmasq
<bash> sudo /etc/init.d/dnsmasq restart </bash>

== Set up the Firewall ==
* Save the following two scripts to ~/scripts
=== nat_forward_all.sh ===
<bash>
echo -e "\n\nLoading simple rc.firewall-iptables version $FWVER..\n"
DEPMOD=/sbin/depmod
MODPROBE=/sbin/modprobe

EXTIF="eth0"
INTIF="eth1"
echo " External Interface: $EXTIF"
echo " Internal Interface: $INTIF"

#======================================================================
#== No editing beyond this line is required for initial MASQ testing ==
echo -en " loading modules: "
echo " - Verifying that all kernel modules are ok"
$DEPMOD -a
echo "----------------------------------------------------------------------"
echo -en "ip_tables, "
$MODPROBE ip_tables
echo -en "nf_conntrack, "
$MODPROBE nf_conntrack
echo -en "nf_conntrack_ftp, "
$MODPROBE nf_conntrack_ftp
echo -en "nf_conntrack_irc, "
$MODPROBE nf_conntrack_irc
echo -en "iptable_nat, "
$MODPROBE iptable_nat
echo -en "nf_nat_ftp, "
$MODPROBE nf_nat_ftp
echo "----------------------------------------------------------------------"
echo -e " Done loading modules.\n"
echo " Enabling forwarding.."
echo "1" > /proc/sys/net/ipv4/ip_forward
echo " Enabling DynamicAddr.."
echo "1" > /proc/sys/net/ipv4/ip_dynaddr
echo " Clearing any existing rules and setting default policy.."

iptables-restore <<-EOF
*nat
-A POSTROUTING -o "$EXTIF" -j MASQUERADE
COMMIT
*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A FORWARD -i "$EXTIF" -o "$INTIF" -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -i "$INTIF" -o "$EXTIF" -j ACCEPT
-A FORWARD -j LOG
COMMIT
EOF

echo -e "\nrc.firewall-iptables v$FWVER done.\n"
</bash>
=== nat_block_all.sh ===
<bash>
echo -e "\n\nLoading simple rc.firewall-iptables version $FWVER..\n"
DEPMOD=/sbin/depmod
MODPROBE=/sbin/modprobe

EXTIF="eth0"
INTIF="eth1"
echo " External Interface: $EXTIF"
echo " Internal Interface: $INTIF"

#======================================================================
#== No editing beyond this line is required for initial MASQ testing ==
echo -en " loading modules: "
echo " - Verifying that all kernel modules are ok"
$DEPMOD -a
echo "----------------------------------------------------------------------"
echo -en "ip_tables, "
$MODPROBE ip_tables
echo -en "nf_conntrack, "
$MODPROBE nf_conntrack
echo -en "nf_conntrack_ftp, "
$MODPROBE nf_conntrack_ftp
echo -en "iptable_nat, "
$MODPROBE iptable_nat
echo -en "nf_nat_ftp, "
$MODPROBE nf_nat_ftp
echo "----------------------------------------------------------------------"
echo -e " Done loading modules.\n"
echo " Enabling forwarding.."
echo "1" > /proc/sys/net/ipv4/ip_forward
echo " Enabling DynamicAddr.."
echo "1" > /proc/sys/net/ipv4/ip_dynaddr
echo " Clearing any existing rules and setting default policy.."

iptables-restore <<-EOF
*nat
-A POSTROUTING -o "$EXTIF" -j MASQUERADE
COMMIT
*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A FORWARD -i "$INTIF" -j LOG
-A FORWARD -i "$INTIF" -j REJECT
COMMIT
EOF

echo -e "\nrc.firewall-iptables v$FWVER done.\n"
</bash>
* Make both scripts executable
<bash>
chmod a+x ~/scripts/nat_block_all.sh
chmod a+x ~/scripts/nat_forward_all.sh
</bash>
* Test the wide-open script. Inspect the output for errors indicating something is wrong.
<bash>
sudo ~/scripts/nat_forward_all.sh
</bash>
* If the previous command was successful and you got dns and dhcp configured before, you should be able to connect through your gateway on computers on the internal network.
* Test this now, by connecting a test computer to the network if you haven't already. Try browsing the web on one of the test machines as a quick test. Use '''ipconfig /all''' or '''ifconfig''' to see how the test computer is being configured. Expected values are below: 
{| class="lltable" border="1"
|+ '''Test Machine Network Parameters'''

|--
!Parameter
!Expected Value

|--
| IP Address
| 192.168.1.50-192.168.1.150

|--
| Subnet Mask
| 255.255.255.0

|--
| Default Gateway
| 192.168.1.1

|--
| Nameserver (DNS Server)
| 192.168.1.1

|}

* If everything seems to be working correctly, make the wide-open config run during system startup.
<bash>
sudo cp nat_forward_all.sh /etc/init.d/nat.sh
sudo ln -s /etc/init.d/nat.sh /etc/rc2.d/S95masquradescript
</bash>

== Set up the SOCKS 5 proxy==
* Replace /etc/danted.conf with the following.
<pre>
#logoutput: stderr
logoutput: syslog
#the above line will send any logs to /var/log/syslog instead to a terminal

internal: eth1 port = 1080

external: eth0

method: username none
#the above puts no username or password. Access will instead be controlled via client ip address/range.
#if there is no username or password - then danted socks server needs to run as nobody, i.e.

#user.privileged: proxy
user.notprivileged: nobody

### "client-rules" ###
#client pass {
# from: 136.201.251.21/0 port 1-65535 to: 0.0.0.0/0
# # 136.201.251.21/0 = specific ip address.
# }

client pass {
from: 192.168.1.0/16 port 1-65535 to: 0.0.0.0/0
}

client block {
from: 0.0.0.0/0 to: 0.0.0.0/0
log: connect error
}

### "socks-rules" ###
block {
from: 0.0.0.0/0 to: 127.0.0.0/8
log: connect error
}

pass {
from: 192.168.1.0/16 to: 0.0.0.0/0
protocol: tcp udp
}

pass {
from: 127.0.0.0/8 to: 0.0.0.0/0
protocol: tcp udp
}

block {
from: 0.0.0.0/0 to: 0.0.0.0/0
log: connect error
}
</pre>
* Start the proxy server
<bash> sudo /etc/init.d/danted restart </bash>
* If you get a "Failed to open libc.so..." error message when starting the proxy server, this is caused by a [https://bugs.launchpad.net/ubuntu/+source/dante/+bug/767085 mistake] in the dante-server debian package. To work around this, create a simlink to the correct libc.so and try to start danted again.
<bash> sudo ln -sf /lib/i386-linux-gnu/libc-2.13.so /lib/i386-linux-gnu/libc.so </bash>
* Test connecting through the proxy by configuring the web browser on one of the test machines connected through the gateway to use the proxy.
* Restrict outgoing traffic through the gateway by enabling the more restrictive iptables configuration.
<bash> sudo ~/scripts/nat_block_all.sh </bash>
* In the proxy options section of the browser, supply 192.168.1.1 as the SOCKS server and 1080 as the port.
* Attempt to browse to an internet website. If you can browse as usual, the proxy is working correctly.
* Disable the proxy in the browser.

== Set up the HTTP (Web) proxy ==
* Edit /etc/squid/squid.conf. We will be editing the existing file instead of replacing it.
* Look for the following line:
http_port 3128
* Replace with the following:
http_port 192.168.1.1:3128
cache
* Look for the following lines:
acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network

* Replace with
acl localnet src 192.168.1.0/8 # RFC1918 possible internal network

* Look for the following line:
http_access allow localhost
* Append another line after it so that it now looks like this:
http_access allow localhost
http_access allow localnet

* A patch to do the above:
<diff>
--- squid.conf.original 2011-07-11 13:58:12.640564821 -0400
+++ squid.conf 2011-07-11 14:37:18.640566228 -0400
@@ -606,9 +606,7 @@
# Example rule allowing access from your local networks.
# Adapt to list your (internal) IP networks from where browsing
# should be allowed
-acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
-acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
-acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
+acl localnet src 192.168.1.0/8 # RFC1918 possible internal network
#
acl SSL_ports port 443 # https
acl SSL_ports port 563 # snews
@@ -675,6 +673,8 @@
# from where browsing should be allowed
#http_access allow localnet
http_access allow localhost
+http_access allow localnet
+

# And finally deny all other access to this proxy
http_access deny all
@@ -1111,8 +1111,9 @@
# visible on the internal address.
#
# Squid normally listens to port 3128
-http_port 3128
+http_port 192.168.1.1:3128

+cache deny all
# TAG: https_port
# Note: This option is only available if Squid is rebuilt with the
# --enable-ssl option
</diff>

* Restart the squid proxy:
<bash>
sudo stop squid
sudo start squid
</bash>
* Examine syslog for any errors
<bash>
sudo tail /var/log/syslog
</bash>
* Try to connect through the http proxy.
* In the proxy options section of the browser, supply 192.168.1.1 as thettings in a web browser on the test machine that is behind the firewall.
* Restrict outgoing traffic through the gateway by enabling the more restrictive iptables configuration.
<bash> sudo ~/scripts/nat_block_all.sh </bash>
* In the proxy options section of the browser, supply 192.168.1.1 as the HTTP proxy server and 3128 as the port.
* Attempt to browse to an internet website. If you can browse as usual, the proxy is working correctly.
* Disable the proxy in the browser.

== Cleanup ==
* Reboot the machine, using the graphical menus to reboot or the following command. Verify that everything still works as before.
<bash> sudo shutdown -r now </bash>
* Note that we left the unrestricted firewall configuration as the default. When the gateway is rebooted, you will need to rerun '''~/scripts/nat_blocked_all.sh''' to restrict connections again. If you would like that to be the default state, copy '''~/scripts/nat_blocked_all.sh''' to '''/etc/init.d/nat.sh'''.

= Useful References =
If you run into difficulties with these instructions, there is more information in the official documentation. I based the configurations in this document mostly from the following sites:
*[https://help.ubuntu.com/community/Router Ubuntu Router Instructions]

File:Socks test setup.2.png

2011-07-11T21:49:10Z

Log Linden:

File:Socks test setup.png

2011-07-11T21:48:42Z

Log Linden: uploaded a new version of "File:Socks test setup.png": test setup without obnoxious border

Test setup for SOCKS 5 proxy testing of the viewer.

File:Socks test setup.png

2011-07-11T21:46:44Z

Log Linden: uploaded a new version of "File:Socks test setup.png"

Test setup for SOCKS 5 proxy testing of the viewer.

File:Socks test setup.png

2011-07-11T21:45:43Z

Log Linden: uploaded a new version of "File:Socks test setup.png"

Test setup for SOCKS 5 proxy testing of the viewer.

File:Socks test setup.png

2011-07-11T21:45:21Z

Log Linden: uploaded a new version of "File:Socks test setup.png"

Test setup for SOCKS 5 proxy testing of the viewer.

User:Log Linden/Socks5Viewer/TestPlan/ProxyGateway

2011-07-11T21:44:05Z

Log Linden: /* Connect network hardware */ Added diagram of network setup

= Introduction =
These instructions will help you set up a simple Ubuntu gateway machine that will allow you to control access to the outside network for computers that are operating behind the gateway. This setup was created for testing the SOCKS 5 proxy. With some modification, the same setup could be used for testing various other network conditions, including throttling the connection speed down to something closer to residential DSL speeds. The instructions are intended for someone with a reasonable familiarity with Ubuntu Linux and will only discuss the customisations needed to set up the gateway.

= Requirements =
== Hardware ==
* A standard off-the-shelf PC with two Ethernet NICs
* 1 Ethernet switch for the "internal" network
* Network cables
* Other computers to actually run the viewer on.
== Software ==
* Ubuntu Linux 11.04 (Natty) [http://www.ubuntu.com/download/ubuntu/download install media] (Other flavors of Ubuntu, including Ubuntu server should work with these instructions as well.)

= Instructions =
== Connect network hardware ==
* Connect one network card to the outside network.
* Connect the other network card to the internal ethernet switch.
* Connect testing computers to the internal network switch.
[[File:Socks_test_setup.png]]

== Install Ubuntu and Packages ==
* Install Ubuntu on the gateway machine. Consult the official Ubuntu install [https://help.ubuntu.com/community/GraphicalInstall instructions] for more information.
* Reboot into the installed system.
* Update the packages on the system.
<bash>
sudo apt-get update
sudo apt-get upgrade
</bash>
* Install some additional useful packages that we will need.
<bash> sudo apt-get install dnsmasq dante-server openssh </bash>
== Configure Network Interfaces ==
* IMPORTANT NOTE: For the purpose of this document, eth0 is the device that is connecting to the outside network, and eth1 is connecting to the internal network. Verify which is which on your setup.
<bash>ifconfig</bash>
Chances are, only one of the ethX devices will have been assigned an IP address by your network, this is the one connected to the external network. If this is not eth0 you need to either switch the network cables connected to the computer or remember to swap the interface names everywhere in the rest of this document. We are going to be assigning eth1 with a static IP address, which can cause problems if it conflicts with the rest of your network.
* Edit, with sudo, '/etc/network/interfaces' and replace its contents with the following
<bash>
auto lo eth0 eth1

iface lo inet loopback

# External network
iface eth0 inet dhcp

# Internal network
iface eth1 inet static
address 192.168.1.1
network 192.168.1.0
netmask 255.255.255.0
broadcast 192.168.1.255
</bash>
* This configuration makes eth0 continue to get its configuration through DHCP, and statically configures eth1. Listing both interfaces on the auto line will mean that they will automatically connect on startup.
* Because we are setting up the interfaces in this config file, we should probably prevent networkmanager from trying to do it as well.
<bash> sudo update-rc.d NetworkManager remove</bash>
* Restart the network
<bash>
sudo /etc/init.d/networking stop
sudo /etc/init.d/networking start
</bash>
* Verify the network configuration by looking for the correct IP addresses for eth0 and eth1.
<bash> ifconfig</bash>

== Set up DNS and DHCP ==
* dnsmasq is a lightweight combination DNS/DHCP server. For the anticipated number of clients for this network, it should be sufficient.
* Warning: Again, it is important to get the network interfaces correct for this. Running a rogue DHCP server on the wrong interface could cause major network problems. eth1 should be the '''internal''' network card.
* Replace /etc/dnsmasq.conf with the following:
<bash>
interface=eth1

dhcp-range=192.168.1.50,192.168.1.150,12h
dhcp-authoritative
dhcp-script=/bin/echo
</bash>
* Restart dnsmasq
<bash> sudo /etc/init.d/dnsmasq restart </bash>

== Set up the Firewall ==
* Save the following two scripts to ~/scripts
=== nat_forward_all.sh ===
<bash>
echo -e "\n\nLoading simple rc.firewall-iptables version $FWVER..\n"
DEPMOD=/sbin/depmod
MODPROBE=/sbin/modprobe

EXTIF="eth0"
INTIF="eth1"
echo " External Interface: $EXTIF"
echo " Internal Interface: $INTIF"

#======================================================================
#== No editing beyond this line is required for initial MASQ testing ==
echo -en " loading modules: "
echo " - Verifying that all kernel modules are ok"
$DEPMOD -a
echo "----------------------------------------------------------------------"
echo -en "ip_tables, "
$MODPROBE ip_tables
echo -en "nf_conntrack, "
$MODPROBE nf_conntrack
echo -en "nf_conntrack_ftp, "
$MODPROBE nf_conntrack_ftp
echo -en "nf_conntrack_irc, "
$MODPROBE nf_conntrack_irc
echo -en "iptable_nat, "
$MODPROBE iptable_nat
echo -en "nf_nat_ftp, "
$MODPROBE nf_nat_ftp
echo "----------------------------------------------------------------------"
echo -e " Done loading modules.\n"
echo " Enabling forwarding.."
echo "1" > /proc/sys/net/ipv4/ip_forward
echo " Enabling DynamicAddr.."
echo "1" > /proc/sys/net/ipv4/ip_dynaddr
echo " Clearing any existing rules and setting default policy.."

iptables-restore <<-EOF
*nat
-A POSTROUTING -o "$EXTIF" -j MASQUERADE
COMMIT
*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A FORWARD -i "$EXTIF" -o "$INTIF" -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -i "$INTIF" -o "$EXTIF" -j ACCEPT
-A FORWARD -j LOG
COMMIT
EOF

echo -e "\nrc.firewall-iptables v$FWVER done.\n"
</bash>
=== nat_block_all.sh ===
<bash>
echo -e "\n\nLoading simple rc.firewall-iptables version $FWVER..\n"
DEPMOD=/sbin/depmod
MODPROBE=/sbin/modprobe

EXTIF="eth0"
INTIF="eth1"
echo " External Interface: $EXTIF"
echo " Internal Interface: $INTIF"

#======================================================================
#== No editing beyond this line is required for initial MASQ testing ==
echo -en " loading modules: "
echo " - Verifying that all kernel modules are ok"
$DEPMOD -a
echo "----------------------------------------------------------------------"
echo -en "ip_tables, "
$MODPROBE ip_tables
echo -en "nf_conntrack, "
$MODPROBE nf_conntrack
echo -en "nf_conntrack_ftp, "
$MODPROBE nf_conntrack_ftp
echo -en "iptable_nat, "
$MODPROBE iptable_nat
echo -en "nf_nat_ftp, "
$MODPROBE nf_nat_ftp
echo "----------------------------------------------------------------------"
echo -e " Done loading modules.\n"
echo " Enabling forwarding.."
echo "1" > /proc/sys/net/ipv4/ip_forward
echo " Enabling DynamicAddr.."
echo "1" > /proc/sys/net/ipv4/ip_dynaddr
echo " Clearing any existing rules and setting default policy.."

iptables-restore <<-EOF
*nat
-A POSTROUTING -o "$EXTIF" -j MASQUERADE
COMMIT
*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A FORWARD -i "$INTIF" -j LOG
-A FORWARD -i "$INTIF" -j REJECT
COMMIT
EOF

echo -e "\nrc.firewall-iptables v$FWVER done.\n"
</bash>
* Make both scripts executable
<bash>
chmod a+x ~/scripts/nat_block_all.sh
chmod a+x ~/scripts/nat_forward_all.sh
</bash>
* Test the wide-open script. Inspect the output for errors indicating something is wrong.
<bash>
sudo ~/scripts/nat_forward_all.sh
</bash>
* If the previous command was successful and you got dns and dhcp configured before, you should be able to connect through your gateway on computers on the internal network.
* Test this now, by connecting a test computer to the network if you haven't already. Try browsing the web on one of the test machines as a quick test. Use '''ipconfig /all''' or '''ifconfig''' to see how the test computer is being configured. Expected values are below: 
{| class="lltable" border="1"
|+ '''Test Machine Network Parameters'''

|--
!Parameter
!Expected Value

|--
| IP Address
| 192.168.1.50-192.168.1.150

|--
| Subnet Mask
| 255.255.255.0

|--
| Default Gateway
| 192.168.1.1

|--
| Nameserver (DNS Server)
| 192.168.1.1

|}

* If everything seems to be working correctly, make the wide-open config run during system startup.
<bash>
sudo cp nat_forward_all.sh /etc/init.d/nat.sh
sudo ln -s /etc/init.d/nat.sh /etc/rc2.d/S95masquradescript
</bash>

== Set up the SOCKS 5 proxy==
* Replace /etc/danted.conf with the following.
<pre>
#logoutput: stderr
logoutput: syslog
#the above line will send any logs to /var/log/syslog instead to a terminal

internal: eth1 port = 1080

external: eth0

method: username none
#the above puts no username or password. Access will instead be controlled via client ip address/range.
#if there is no username or password - then danted socks server needs to run as nobody, i.e.

#user.privileged: proxy
user.notprivileged: nobody

### "client-rules" ###
#client pass {
# from: 136.201.251.21/0 port 1-65535 to: 0.0.0.0/0
# # 136.201.251.21/0 = specific ip address.
# }

client pass {
from: 192.168.1.0/16 port 1-65535 to: 0.0.0.0/0
}

client block {
from: 0.0.0.0/0 to: 0.0.0.0/0
log: connect error
}

### "socks-rules" ###
block {
from: 0.0.0.0/0 to: 127.0.0.0/8
log: connect error
}

pass {
from: 192.168.1.0/16 to: 0.0.0.0/0
protocol: tcp udp
}

pass {
from: 127.0.0.0/8 to: 0.0.0.0/0
protocol: tcp udp
}

block {
from: 0.0.0.0/0 to: 0.0.0.0/0
log: connect error
}
</pre>
* Start the proxy server
<bash> sudo /etc/init.d/danted restart </bash>
* If you get a "Failed to open libc.so..." error message when starting the proxy server, this is caused by a [https://bugs.launchpad.net/ubuntu/+source/dante/+bug/767085 mistake] in the dante-server debian package. To work around this, create a simlink to the correct libc.so and try to start danted again.
<bash> sudo ln -sf /lib/i386-linux-gnu/libc-2.13.so /lib/i386-linux-gnu/libc.so </bash>
* Test connecting through the proxy by configuring the web browser on one of the test machines connected through the gateway to use the proxy.
* Restrict outgoing traffic through the gateway by enabling the more restrictive iptables configuration.
<bash> sudo ~/scripts/nat_block_all.sh </bash>
* In the proxy options section of the browser, supply 192.168.1.1 as the SOCKS server and 1080 as the port.
* Attempt to browse to an internet website. If you can browse as usual, the proxy is working correctly.
* Disable the proxy in the browser.

== Set up the HTTP (Web) proxy ==
* Edit /etc/squid/squid.conf. We will be editing the existing file instead of replacing it.
* Look for the following line:
http_port 3128
* Replace with the following:
http_port 192.168.1.1:3128
cache
* Look for the following lines:
acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network

* Replace with
acl localnet src 192.168.1.0/8 # RFC1918 possible internal network

* Look for the following line:
http_access allow localhost
* Append another line after it so that it now looks like this:
http_access allow localhost
http_access allow localnet

* A patch to do the above:
<diff>
--- squid.conf.original 2011-07-11 13:58:12.640564821 -0400
+++ squid.conf 2011-07-11 14:37:18.640566228 -0400
@@ -606,9 +606,7 @@
# Example rule allowing access from your local networks.
# Adapt to list your (internal) IP networks from where browsing
# should be allowed
-acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
-acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
-acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
+acl localnet src 192.168.1.0/8 # RFC1918 possible internal network
#
acl SSL_ports port 443 # https
acl SSL_ports port 563 # snews
@@ -675,6 +673,8 @@
# from where browsing should be allowed
#http_access allow localnet
http_access allow localhost
+http_access allow localnet
+

# And finally deny all other access to this proxy
http_access deny all
@@ -1111,8 +1111,9 @@
# visible on the internal address.
#
# Squid normally listens to port 3128
-http_port 3128
+http_port 192.168.1.1:3128

+cache deny all
# TAG: https_port
# Note: This option is only available if Squid is rebuilt with the
# --enable-ssl option
</diff>

* Restart the squid proxy:
<bash>
sudo stop squid
sudo start squid
</bash>
* Examine syslog for any errors
<bash>
sudo tail /var/log/syslog
</bash>
* Try to connect through the http proxy.
* In the proxy options section of the browser, supply 192.168.1.1 as thettings in a web browser on the test machine that is behind the firewall.
* Restrict outgoing traffic through the gateway by enabling the more restrictive iptables configuration.
<bash> sudo ~/scripts/nat_block_all.sh </bash>
* In the proxy options section of the browser, supply 192.168.1.1 as the HTTP proxy server and 3128 as the port.
* Attempt to browse to an internet website. If you can browse as usual, the proxy is working correctly.
* Disable the proxy in the browser.

== Cleanup ==
* Reboot the machine, using the graphical menus to reboot or the following command. Verify that everything still works as before.
<bash> sudo shutdown -r now </bash>
* Note that we left the unrestricted firewall configuration as the default. When the gateway is rebooted, you will need to rerun '''~/scripts/nat_blocked_all.sh''' to restrict connections again. If you would like that to be the default state, copy '''~/scripts/nat_blocked_all.sh''' to '''/etc/init.d/nat.sh'''.

= Useful References =
If you run into difficulties with these instructions, there is more information in the official documentation. I based the configurations in this document mostly from the following sites:
*[https://help.ubuntu.com/community/Router Ubuntu Router Instructions]

File:Socks test setup.png

2011-07-11T21:42:54Z

Log Linden: Test setup for SOCKS 5 proxy testing of the viewer.

Test setup for SOCKS 5 proxy testing of the viewer.