Fix Web UI link error

In the Web UI footer, the link cannot lead user to the correct
site. This patch fix it.

update formatting of README.md

Update floodlightdefault.properties

Fixed action serializer for actions that do not have values

add the ACL application support

Fixed action serializer for actions that do not have values e.g. strip_vlan and such. Added in a 'n/a' value for the JSON key's value. Perhaps we should rethink how a list of actions is serialized to avoid the 'n/a' all together.

Update readme

Finally got around to fixing LearningSwitch.

First round of support for changing switch roles via modules and REST API.

Fixed issue where multipart flow replies would only show the last part/reply and not print the others. Only a REST API issue. This will also fix the Web UI where people reported not seeing all their flows.

Modified slightly to track the specific initial state. If we were slave first, then we won't clear the flow table if we go to master for the first time.

Added ability to customize start/role-transition behavior at the request of an individual a while ago. Using floodlightdefault.properties, you can specify if you want the controller to clear the flow tables of switches (1) upon inital handshake and transition to master or (2) upon every transition to master. Or you can not ever clear the tables if you want.

Added ability to switch OF roles per DPID or for all switches at once. This includes a REST interface and integration with the handshake and channel handlers in order to keep the switch in the correct state. An IOFConnectionListener also has the ability to listen for messages that are written now instead of read from the wire. This allows modules to write role requests, have the underlying handshake/channel substrate tap in and listen to the request, and automatically update the role of the switch when the response comes back.

Include commits for last pull request

Fixed OFChannelHandler to always allow echo requests and replies no matter the state in the handshake process. This issue was discovered during an unsuccessful handshake with an HP 5900af, which for whatever reason wants to handshake as follows: ... (1) FL features request, (2) HP echo request, (3) FL echo reply, (4) HP features reply. There are still issues with this switch after the handshake completes, but an echo should be honored in any state.

Correct the spelling error

Fixed fetching of ingress port to work with OF1.0 and 1.2+. This is the final commit for the DHCP server. Will add some unit tests in a later and near-future commit as practice/exercise for me =)

Initial DHCP server code commit. This was a test of how easy is is to port v0.91- code to v1.0. I have not tested this module yet. TODO: Write unit tests for the dhcpserver module.

Reapplied the LinkDiscoveryManager's patch from earlier (issue #471). Updated Ethernet.java to use EthType instead of short for EthTypes. In conjunction, bitmasked the LSBs of the ethertype as it is casted from short to int. This preserves the MSB (sign) as a data bit --> unsigned integer.

In line 329 of StaticFlowEntryPusherResource.java, the word "flow mod"
is spelled as "flod mod".
Just encountered that when using the rest api, so I fixed it.

Forwarding's doDropFlow() changed to not base Match on OFPacketIn, which it shouldn't in the first place. We need to first deserialize the packet and use its header attributes. TODO: How much is too much to match on? Sometimes we want a very specific match by default. Other times, we don't. The former creates a larger flow table, while the latter might inadvertently match packets that we don't intend to. Perhaps this should be a user-configurable option? Such as net.floodlightcontroller.Forwarding.matchLayer=L2, L3, or L4?

Undo LinkDiscoveryManager 'bug' fix from a while back. We'll test to see if it's what's causing some issues with invalid ethertypes. Also, includes a patch for OFChannelHandler that will accept the smallest of the OpenFlow versions during the initial handshake.

Submitting a new ACL application to Floodlight

HTTPS Support for the REST API

Updated Restlet from 2.2M3 to 2.3.1. Included with the update is full SSL support for the REST API, either all-access+encryption or restricted-access+encryption (truststore verified clients only). Additional options have been added to floodlightdefault.properties in order to turn HTTPS on/off. HTTPS ccan be used in conjunction with vanilla HTTP as well -- each must reside on a different TCP port though. Also, this time, I remembered to update and test the build.xml file to remove the old and include the new Restlet jars.

Oops. Update build.xml with new Netty 3.10.0 jar file name.