Speech:Spring 2017 Julian Consoli Log


 * Home
 * Semesters
 * Spring 2017
 * Proposal
 * Report
 * Information - General Project Information
 * Experiments - List of speech experiments

Week Ending February 7th, 2017
''I have submitted this week's log entries late. My fault entirely, I did not think we had to do log entries for the first week.''

Feb/1
The main task that was to be done today was to go over schedules with the other group members. During this time we would outline our availability and come up with a game-plan regarding what days we could meet and what times we could meet. This is an important step because if we have no semblance of when we are meeting to discuss the project, then we are setting ourselves up for failure.
 * Task:

As a group we created a spreadsheet of what times we were unavailable. We determined that Thursday would be the best day when we could all meet up in person, and Monday-Wednesday would be good, as long as it was in the evening. Weekends were basically out for meeting in person, but we can have group meetings over Google Hangouts if necessary.
 * Results:

The next step is coming up with a project proposal so we can get an idea of what we should be doing. My main concern is where we are going to house this proposal document. We are not going to have the chance to meet up so we would have to pass around a Word document. We need to find a better solution for working on documents collaboratively.
 * Plan:
 * Concerns:

Feb/2
Checking in. Not much was done today. I started a rough draft of the proposal document, but I am still not sure how to proceed. Andrew said he was going to set up VPN access for the group on his server, but he will start working on that closer to Saturday.
 * Task:

I am awaiting the results of Andrew's work with the VPN access before I proceed on the finalization of the proposal draft.
 * Results:

If we can get the file server up and running then we will be able to collaboratively edit documents in real time so it will be much easier to make the proposal. Also, we don't have to worry about all of the proprietary concerns of a service like Google Drive or Dropbox. If we can't get the server up and running then we will have to find a way to all work on the document.
 * Plan:
 * Concerns:

Feb/5
Configure my newly created VPN and OwnCloud account that Andrew had setup. The other task which was the main task to begin with was to finalize the project proposal document for the systems team. I told the group I will come up with the overview and tasks, which we will be able to delegate as a group afterwards.
 * Task:

I was able to share the proposal document I had created thus far and finalize the overview and game plan. I was not sure how we should split up the tasks and I was also unsure if I was missing any tasks so I informed my group that they should look over it first, and then we can assign tasks.
 * Results:

I am awaiting a response from the other group members to get their thoughts on who should do what and when we expect to get it done. No concerns at this present moment, i am sure that my group members will be able to read the document in time for us to post it on the Wiki.
 * Plan:
 * Concerns:

Feb/7
I need to post the project proposal on the wiki page, however I have not heard back from anyone if they had the chance to look over the document. I think the proposal is due by the end of the day of class, but I assume that sooner rather than later is the preferred method of action.
 * Task:

I did not hear back so I sent out a message stating that one of them would have to post the proposal on the wiki because I would not have access to my personal computer until the beginning of class tomorrow.
 * Results:

The plan is to check in before class to see if the wiki page has been filled out. I will also need to inform them of my tasks in that span of time which I have not determined how I am going to do so. I am concerned that I will not be able to fill out my tasks on the wiki page before it is due. However if the proposal is due at the end of class, then I should be fine.
 * Plan:
 * Concerns:

Feb/8
The main task was to get more familiar with the errors that we are seeing on the servers as well as take a closer inspection of how the servers are setup. Our main issue we noticed the first week was that we could not access any of the drones via ssh or telnet from Caesar. I'm not sure if this was intentional or not, but I am going to safely assume that we need management access to those devices. I remember that Andrew was able to the IP mapping of the devices, but we could not resolve a ping to the IP address. I am not sure if we need to connect via the domain name.
 * Task:

We were able to assess what errors were coming across the machines. Rome and Caesar both had the following error codes: E1624, E1614, and E164C. The first error was that there was a power supply redundancy issue found. The next issue was similar to that in which it listed what power supply was not found, and similarly so did the third issue which stated that it had been lost. In both cases it stated that power supply one was not found. I checked in the back of the servers and noticed that the right sides of the units were connected, but not the left side. Typically we read left to right, so I assumed that power supply one was the supply on the left which was disconnected. The other error was looked into by Andrew and Bonnie. I am not sure of the results of the diagnosis, so I will have to followup with them.
 * Results:

I think the next step is to determine if both power supplies are intended to be used or are they unplugged for a reason. Also, I am wondering why we don't have any type of UPS or PDU for these servers. It looks like they are connected to plain power strips instead of surge protectors, so I am not sure what is protecting these devices from power failures. This is something we may need to address in the future because UPS' and PDU's can be expensive. Similar to what I stated in the plan, I am wondering if these errors always existed or if at one point there was a secondary backup power supply plugged in.
 * Plan:
 * Concerns:

Feb/12
The main task was to think of different ways to monitor the servers remotely. There are going to be times when members of the systems team are not going to have access to maintenance the servers. A prime example is when we have snow storms that result in the university being closed. We need a means of diagnosing and managing any errors the machines may encounter, remotely. We currently have means of logging into Caesar through the UNH VPN, but without physically being in the room to read the errors on the servers, it makes it more cumbersome to monitor the servers.
 * Task:

One way we could go about solving this problem is through a SNMP type feature which could report back diagnostic information. We originally were going to set up IDRAC devices, but this would end up costing us more money in the long run because we would have to keep paying UNH for the monthly fees for the IP addresses.
 * Results:

The plan is to keep researching different types of monitoring that would be idle for our setup.
 * Plan:

My main concern is that we really have no other way of remotely monitoring the devices, and the best approach we have is to be there in person.
 * Concerns:

Feb/13
I believe Andrew and Mark have the remote monitoring covered for the servers so I was looking for other tasks to do. Unfortunately the university is closed today and we still don't have our security badges to gain access to the server rooms. While looking through the documentation, I found little to no understanding of how to mount/unmount the drones. For something that is apparently so crucial and risky, I would think that there would be something that is flashing red and says 'Here are the instructions'. I guess the next task is to figure out how to mount and unmount the drives and properly document the steps.
 * Task:

I could not do so today because the university is closed. It is true that I could remote in, but I would prefer to be in the same location as the devices when doing it for the first time. Also I would need to work with the other group members so we can all be comfortable with mounting and unmounting the drones.
 * Results:

We need to first obtain our badges so we can have access to the room, and then we need to set up a day that we are all available to test out the servers.
 * Plan:

I hope we get our badges in time, because time is running out.
 * Concerns:

Feb/14
Checking in. Not much that I could do today. I was at work.
 * Task:

Supposedly we will be getting our badges tomorrow so we can access the room.
 * Results:

Obtain badges from security desk.
 * Plan:

We are going to have a lot of catching up to do.
 * Concerns:

Feb/16
The main task was to create an SSH keygen that would allow access to the other servers without having to retype your credentials. The steps themselves were pretty straight forward, and after we verified that they worked we had to document it and send it to the other teams.
 * Task:

I was able to successfully create the SSH keygen for my user account and verified I could access the other servers without re-entering a password after SSH-ing from caesar. I began work on a document that will compile the work we have done and may need to be done for future semesters.
 * Results:

Figure out a better means of organizing the wiki documentation for the systems team. Right now it is pretty difficult to navigate (in my opinion). I was not present in the meeting for the decode, so I need to figure out how that went.
 * Plan:
 * Concerns:

Feb/19
Checking in mostly. Last night we went over the project proposal once again, touched upon Torque and looked into the IRC server.
 * Task:

We ran into a hurdle in regards to the IRC server. Last semester, Neil had managed to download the zip and extracted the files necessary to run the server, however, he did not download a compiler such as GCC or G++. We attempted to do so. Unfortunately Rome does not have internet access so we were unable yum install the compilers. We reached out to Bruce in hopes he would be able to assist us in gaining internet access drone machines including Rome.
 * Results:

We are going to be in the server room tomorrow working on the machines and possibly configuring/installing Torque. Unfortunately we can not proceed any further on the IRC until we have internet access on Rome. We were hoping that we would be able to set up the IRC to replace Slack. While Slack is a good option for an IRC, we as the systems team feel that it would be better to have an in house chat server in case we needed to securely communicated information.
 * Plan:
 * Concerns:

Feb/20
Setup IRC server and start looking into setting up Torque on Asterix and Idefix. About mid-way into setting up the IRC, we were tasked with setting up NFS on majestix. We had to make sure that /mnt/main was pointed on it.
 * Task:

Worked with Bonnie and Mark to get the /mnt/main directory on majestix. We followed the guide on the wiki by setting up the Volume Group, then mounting the point and finally setting up the file system. We were successful in bringing /mnt/main to majestix. One of the main hurdles we ran into was that the host file was not filled out on majestix. We had just assumed it would be, but upon closer inspection it was not. Added hosts, and Mark also configured the DNS server, and created a chron job for the /mnt/main.
 * Results:

We need to finish up setting up /mnt/main if the professor is still unable to add the users. If not, then we can continue setting up IRC and Torque. I have a feeling we probably missed something when setting up the /mnt/main, but the professor will be able to let us know if he can or cannot add users. Hopefully that is done before class on Wednesday.
 * Plan:
 * Concerns:

Feb/21
Develop documentation for the servers. The start of this documentation will include hardware specs that are visible on the exterior of the servers. I could not find anything like this currently on the wiki.
 * Task:

Documented all servers excluding of course Methusalix which we were instructed not to touch and Caesar which should never be touched. I documented such information such as were all ports working (VGA, USB, etc.) what errors were currently coming across the information LCDs, what interfaces were connected and where the ethernet cables connected, and the status of the power supplies. This information is useful for if/when the servers need to be disconnected and reconnected.
 * Results:

The next step is to add that information to the wiki and combine it with Andrew's hardware information update. I might as well document Caesar and Methusalix when I get the chance.
 * Plan:
 * Concerns:

Feb/22
Download GCC/G++ onto Rome so we can start the IRC server.
 * Task:

The professor had provided us with a link to a cable that connected directly to a device that was providing DHCP for internet access. Previously the machines did not have internet access so it was impossible to download GCC/G++. While attempting to connect Rome to the internet, we ran into some hurdles with IP conflicts, registration issues, and ultimately (as discovered by Mark) DNS issues. We were able to resolve Google's DNS server IP through ping, but we could not resolve www.google.com. Re-configuring the DNS statically to match Caesar's was not working. Every time we rebooted the device it would default the network settings.
 * Results:

Now that we have the means to get out tot he internet, we need resolve the DNS issues we are getting. If we manage to get this to work on Rome, then we will be able to apply this technique to the other servers in case the need to install compilers. We not only need to get the internet working for the IRC, but we also need to install Torque with it, so it is imperative that we get this up and running.
 * Plan:
 * Concerns:

Feb/26
Download GCC/G++ and install it on Rome so we can set up the IRC server. Subtasks of this include getting Rome connected to the Internet, setting up the subscription manager and performing the yum install. I had worked with Mark last week to attempt to resolve the DNS issues that Rome was receiving. Mark was able to figure out the issue. We were previously entering the config setting incorrectly for static-ing the DNS. Mark entered the config setting correctly and was able to resolve pings to Google.
 * Task:

I attempted to register the server using the command 'subscription-manager register'. Previously we attempted to enter the same command with the organization and activation key that were provided to us by Bruce. The supplementary parameters are '--org="UNHM" --key= '. However, we were unable to reach that organization and the subscription manager did not recognize it. It is possible to register and attach an organization at a later date, however when I was prompted for a username and password, the credentials were being rejected.
 * Results:

We need to find out if there are different credentials for the RHN instead of the credentials to access the server. No concerns at the moment.
 * Plan:
 * Concerns:

Feb/27
Checking in. I did not have enough time to work on the project by the time I got home.
 * Task:

Checking in. I did not have enough time to work on the project by the time I got home.
 * Results:

Checking in. I did not have enough time to work on the project by the time I got home. Checking in. I did not have enough time to work on the project by the time I got home.
 * Plan:
 * Concerns:

Feb/28
Look into CentOS as an alternative to the Red Hat repositories for yum installs.
 * Task:

CentOS is basically a derivative of Red Had that doesn't require registrations or subscriptions. Additionally, it is almost identical in terms of compatibility with the versions of Red Hat. If we are able to switch over to CentOS' repository, then we can bypass the the required registration key on the machines. This would allow us to download Torque, GCC, and G++.
 * Results:

Work on the servers tomorrow in class with the other group members to configure repository. We have been trying many solutions to work around the hurdles of not having access to the registration keys.
 * Plan:
 * Concerns:

Mar/2
Get GCC/G++ installed on Rome for the IRC server to run.
 * Task:

We were able to yum install GCC/G++ without prompting a username and password for the RedHat registration. One of the workarounds that Mark figured out was to edit the domain server so it could properly access cinnibar.unh.edu
 * Results:

The next step is to turn Rome into a gateway hub so the drone machines can get online as well. Also get the IRC server up and running. I don't think that the wireless dongle we were provided will work as a broadcast antenna. I understand our goal is to make Rome a hub for the other drones to connect to, but I feel like the easier option is to connect the drones to a dummy router that hooks up to UNH's network. It's going to turn out like the state we were in before, running around in circles when there is a much more practical and easier to implement solution.
 * Plan:
 * Concerns:

Mar/5
Upload my documentation to the wiki.
 * Task:

I will be able to do this later on tonight.
 * Results:

This is more of a check in post. I will edit once the documentation has been posted. This is just a checkin at this point in time.
 * Plan:
 * Concerns:

Mar/6
Finish uploading the documentation to the wiki. Work with systems group to get Rome online.
 * Task:

I had finished uploading the documentation to the wiki, but I was still unable to get Rome online. I think there is a secondary DNS file that is causing me issues resolving a domain.
 * Results:

Get Rome online so we can install Tourqe and make it a hub for the other drones to connect to. I do not think it is possible to turn Rome into a gateway/network bridge.
 * Plan:
 * Concerns:

Mar/7
Route traffic through Rome so the drones can gain access to the internet.
 * Task:

I worked on Miraculix to configure the IP settings. Reconnected eth1 back into interface 20 on the Enterasys switch. Still had access to Rome and Caesar. Set IP settings to static the IP to 192.168.10.4, Netmask to 255.255.255.0, and Gateway to 192.168.10.11 (Rome's IP). Still had connectivity to Caesar and Rome, but not Internet. Attempted to reconfigure Internet access on Rome. Connected the orange CAT cable that is connected to UNH's network on interface eth1. I was able to resolve Google's DNS (8.8.8.8), but not google.com. I verified that the DNS settings were correct in the ifcfg-eth1 file, and restarted network services. Still nothing. Rebooted the server, still nothing.
 * Results:

Need to work with the rest of the team to see if I am missing a step. We had the internet working on Rome before, so I am not sure what has changed. The only thing we have done is unplugged the cable and plugged it back in.
 * Plan:
 * Concerns:

Mar/18
Checking In.
 * Task:

Checking In.
 * Results:

Checking In. Checking In.
 * Plan:
 * Concerns:

Mar/19
Research installation of Torque before our installation of Torque on Majestix. There is an installation document that Bonnie had provided.
 * Task:

Read through the document and noted the steps for installing Torque on Redhat. I believe that Bonnie had set up Miraculix as a server so we would have to set up Majestix as a Node Manager/MOM. However I also remember that there was some confusion with what servers would have Torque and the Miraculix install would have to be modified.
 * Results:

We have to install Torque on Majestix tomorrow and have it configured as a server. If necessary we can reconfigure Miraculix. I'm not sure what two servers are going to be running Torque.
 * Plan:
 * Concerns:

Mar/20
Install Torque on Majestix. Work with Mark and Andrew to get Torque up and running using the install guide that Bonnie provided as a guide.
 * Task:

We were able to successfully install Torque on Majestix and it is running properly. Some of the issues we ran into were that the installation instructions that the install guide had were either outdated or incorrect. When we tried downloading the file through a wget, it downloaded an HTML file instead. Come to find out that the URL was completely incorrect and needed to be changed. Once we downloaded the file it was pretty much smooth sailing.
 * Results:

Ask Bonnie what step she had left off when installing Torque on Miraculix. Once we know what step she was stuck on, we can continue with the installation and finish the installation of Torque to run some trains. We may also have to rebuild Miraculix from the ground up.
 * Plan:
 * Concerns:

Mar/21
We need to rebuild Miraculix as there are some DNS issues that still prevent it from properly connecting to the internet. The Torque installation will also be wiped, but after our install yesterday, it should be a piece of cake.
 * Task:

Andrew was available to rebuild Miraculix, and it is now set up successfully and can get out to the internet no problem. We will have the teams tomorrow try and run a train to make sure it is properly set up.
 * Results:

Relay update information in class tomorrow to check to see which team gets Miraculix. No concerns as of yet.
 * Plan:
 * Concerns:

Mar/22
Attempt to finish configuring the wireless dongle that the professor had provided so we can connect to UNH's wifi with Rome. Once this has been set up, the intention is to turn Rome into a network bridge and route traffic to the drones.
 * Task:

Andrew had extracted the Linux installation files off of the disc so all I had to do was build the files. However, therein lied the issue. I was receiving errors when attempting to build the files. The installation instructions were encapsulated in a .ppt file which I had to offload onto an external device that had Microsoft PowerPoint. The instructions stated to enter the 'make' command once the files had been extracted, but I kept receiving an error that stated the following directory did not exist:
 * Results:

/lib/modules/2.6.32-504.el6.i686/build

I ran an ls command in the parent directory and it highlighted build in red (which meant nothing to me). Checked in the file explorer and viewed the properties. Apparently it is a broken/dangling symbolic link to a kernel directory. I wasn't sure if this was an issue on Rome, but I inspected a sample of the other drones and Caesar, and noticed the same issue.

I need to investigate this symbolic link issue before proceeding. I did make sure that this dongle will work on the system. The packaging states it is compatible with Linux kernel version 2.6.0005.20091112.P4. RedHat 6.6 uses kernel version 2.6.3xxx. I'm hoping that this broken symbolic link is something that is fixable and won't affect the other machines.
 * Plan:
 * Concerns:

Mar/23
Checking in
 * Task:

Checking in
 * Results:

Checking in Checking in
 * Plan:
 * Concerns:

Mar/27
I tasked myself with troubleshooting the error I was receiving when attempting to make the drivers for the wireless dongle.
 * Task:

Ran through the install once more to replicate the error. Looked into the "[modules] Error 2" that was being thrown. Apparently this is common when the 'kernel-headers' and 'kernel-devel' packages are missing. Unmounted Rome. Ran a yum install and yum update to make sure these packages were installed and up to date. Outputted list of packages before and after install to a text file. Rebooted Rome to make sure the changes went into affect. Unmounted Rome. Ran through the install again, but I received the same error. Cross referenced the package version and the kernel version and noticed a mismatch. Checked the /lib/modules directory and noticed that there were two kernel versions in that directory. One version had a build file that was properly linked and the other did not.
 * Results:

I need to investigate to see if there is a way to manually specify which kernel version to use when running the make command. I don't know if it is common to have two different kernel versions in the modules directory so I will have to research that as well.
 * Plan:
 * Concerns:

Mar/28
Finish research the dual kernel modules to see if there is a way to specify which build directory to use. Once that has been completed, continue the installation of the drivers for the wireless dongle.
 * Task:

Before I had done the yum updates, there were two kernel versions in the modules directory. When I had done the yum update, for some reason it installed updates on the newer kernel version instead of the kernel version that Rome was running. This meant that kernel-devel was never installed on the kernel that the server uses. Specified the correct version to download and ran a yum install. Install was successful and after a reboot of the machine I was finally able to finish installing the drivers. The install was successful and I was able to see the UNH-Public SSID. We had previously added the MAC to the list of authorized devices on the UNH-Public network. Connected to the network successfully, and I was able to ping Google's DNS and domain as well as browse the internet.
 * Results:

The next step is to see if it is possible to route traffic through Rome so the drones can get internet access. I do not believe this is possible. I was doing some research and I found a link that stated it was not possible to configure a wireless interface as a bridge. Also, UNH's APs may notice that unauthorized devices are attempting to gain access through an authorized device and shut it down.
 * Plan:
 * Concerns:

Mar/29
Checked in.
 * Task:

Worked with Andrew to configure spare Cisco switch.
 * Results:

Checked in. Checked in.
 * Plan:
 * Concerns:

Mar/30
Checked in.
 * Task:

Checked in.
 * Results:

Checked in. Checked in.
 * Plan:
 * Concerns:

Apr/3
Attempt to gain management access to the Enterasys switch. Once management access is obtained, we can look into configuring the switch to route the internet access to the other drones from Rome.
 * Task:

I tried connecting to the switch via DB9 console cable to the console port. I was unsuccessful when I used the DB9 to USB, DB9 to RJ45, and DB9 female to female to USB/RJ45 connectors that we had available. We do not have access to the original console cable that came with the device. Written on top of the switch is an IP address which I assume is the default gateway. Static'ed IP information to my laptop and connected via ethernet to port 23 of the switch. IP - 192.168.188.10 SM - 255.255.255.0 DG - 192.168.188.2 I was able to ping the switch and an arp -a returned a MAC address belonging to Enterasys. I was still unable to telnet to the switch, or resolve it via HTTP. Interestingly, the connections did not time out, they were stuck in a connection loop.
 * Results:

Figure out additional options with the professor to see if we can gain management access to the switch. A reboot of the device may be necessary. We may not have the ability to reboot the switch.
 * Plan:
 * Concerns:

Apr/4
Continue attempting to gain management access to the Enterasys switch. After we gain access, we need to make sure that it can be configured to help setup the network to bring internet to the drones. I need to also research configuring a LAN interface as a router/see if that is possible with our current setup.
 * Task:

Andrew was actually able to console into the switch and provide SSH access to the switch from the drones. It turns out we had a bad console adapter, and we were able to access the switch through a serial connection. We have enabled ssh access, and the existing telnet and HTTP connections. I ran through all the ports on the switch to confirm what interfaces were showing up as well as labeling the ports so we know what is connected to what. There are some interfaces that are showing as up, but there is no layer 2 connection. I need to investigate those in addition to setting up the network.
 * Results:

Priority 1 is making sure it is possible to route internet traffic through LAN interface 2 on Rome and setup NAT entries for the drones. Priority 2 is making sure that all the secondary interfaces on the drones are operational. I'm hoping that the only reason the interfaces are showing down is that they are disabled. If not, we may be dealing with some bad interfaces. It also could be some bad ports, but it is a 48 port switch so there are plenty to swap.
 * Plan:
 * Concerns:

Apr/5
Checked in.
 * Task:

Checked in.
 * Results:

Checked in. Checked in.
 * Plan:
 * Concerns:

Apr/9
Set up the secondary interface on rome as a router so we can give the drones internet access. The guide I used was retrieved from.
 * Task:

First I set the default gateway to the WLAN interface int hte network file located in /etc/sysconfig/ - GATEWAYDEV=wlan0
 * Results:

Next, I set IP packet forwarding to true in the sysctl.conf file - net.ipv4.ip_forward = 1

I then used IP tables to set up the new subnet with a slash 24 (255.255.255.0) netmask iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE iptables -A FORWARD -s 172.10.0.0/24 -j ACCEPT iptables -A FORWARD -d 172.10.0.0/24 -j ACCEPT iptables -A FORWARD -s ! 172.10.0.0/24 -j DROP

And finally saved the new configuration while also making a backup of the old configuration - cp /etc/sysconfig/iptables /etc/sysconfig/iptables.old iptables-save > /etc/sysconfig/iptables

I need to go in tomorrow to test it manually. One of the issues is that for some reason we cannot connect to the UNH ssid remotely. Hopefully what I did works.
 * Plan:
 * Concerns:

Apr/10
Resolve what I had accomplished yesterday by connecting to the UNH-Public ssid and testing.
 * Task:

I had lots of issues reconnecting to the UNH-Public SSID. The main problem is that it keeps disconnecting every 30 minutes. We have attempted multiple times to register the device as a permanent/non-browser device on UNH's network, however the profile keeps getting removed for some reason. I have attempted to connect to UNH-Secure multiple times, but to no avail. I am following the guide step-by-step, but it does not seem to take. Regardless, I have set up the network correctly, and I can resolve the gateway IP of rome when pinging from asterix (which I used as a test).
 * Results:

I need to come back in tomorrow to reconfigure the firewall settings. I hope to get this working.
 * Plan:
 * Concerns:

Apr/11
I need to reconfigure the firewall settings on rome.
 * Task:

Re-entered the previous settings on rome, except I changed the IP schema into a proper subnet of 172.16.0.0. Removed old firewall rules. I am still able to ping rome, but I cannot resolve any internet addresses from the drones. Interestingly, I receive a new error when pinging Google's DNS.
 * Results:

PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data From 172.16.0.11 icmp_seq=1 Destination Host Prohibited

Researching more of this, it points to firewall (iptables) related issues. I found another guide that outlined setting up RHEL as a router and they outline the exact steps to set it up. I'm not sure at this point what firewall is preventing internet traffic across the interfaces.

Need to consult with other group members on how to proceed. I don't know if the firewall rules lie with the drones, rome, or UNH-Public.
 * Plan:
 * Concerns:

Apr/12
Figure out what firewall rule is preventing internet access to the drones.
 * Task:

I was finally able to grant internet access to the drones via Rome. I figured out that the reason I was getting a destination host prohibited when sending ICMP requests was because there was a lingering firewall rule that blocked all routed traffic on the interface, but flagged it as ICMP and returned an ICMP related error. I removed that rule and was able to get internet access.
 * Results:

Set up the rest of the drones to have internet access. The timeout of the UNH-Public session still presents a problem and will need to be addressed.
 * Plan:
 * Concerns:

Apr/16
Start the documentation of how to set up Rome as a router.
 * Task:

I built out a guide and posted in the software setup section of the wiki. This guide includes how to set up Rome as a router. All the necessary commands, files, and rules edited are listed.
 * Results:

Document how to set up the wlan interface drivers and how to configure the drones. No concerns at this moment. I am still happy I got the internet working.
 * Plan:
 * Concerns:

Apr/17
Clean up the firewall rules after setting up Rome as a router and internet on the drones.
 * Task:

I copied down all the firewall rules I had to enter in order to get Rome up and running as a router and the configuration steps necessary in order to grant internet access to the drones. I noticed that the wlan0 interface keeps disconnecting and will not stay logged in. This will be quite cumbersome for future semesters when they want to gain internet access on the drones. While they have the ability to, there is no real way to connect to UNH-Public remotely so someone will have to connect on-site and then perform internet-related operations on the drone.
 * Results:

Finish setting up and configuring the rest of the drones. Having been here for four years, I have seen the wifi go through four different changes in regards to operation/authentication/connectivity. There is no telling how the network will be set up in the future so I am not positive if the current setup will work in the future.
 * Plan:
 * Concerns:

Apr/18
Finish configuring the drones to gain internet access.
 * Task:

Configured the drones to meet the specifications of connecting to the internet. Static'd the secondary interface addresses with a similar IP schema to the primary interfaces. Basically the ending octet is the same on the primary as the secondary, and the only difference is the subnet.
 * Results:

Next is to move on to documentation. Also, Mark may need some assistance connecting to the backup server. I can assist in verifying the connectivity of the server to the internet. No concerns at the moment.
 * Plan:
 * Concerns:

Week Ending April 25, 2017

 * Task:


 * Results:


 * Plan:


 * Concerns:

Week Ending May 2, 2017

 * Task:


 * Results:


 * Plan:


 * Concerns:

Week Ending May 9, 2017

 * Task:


 * Results:


 * Plan:


 * Concerns: