User login

Darren Mason's blog




This week wasn't too productive for my honours as far as progress goes, spent most of my time dealing with other papers.

I have gotten around to fixing my test environment, and that is sort of working. I'm running into an issue where freeradius won't send packets back out after making a reply. I initially thought this was to do with it trying to be clever and sending replies base on client-hardware-address instead of the source MAC (which I'm rewriting), but it's not, instead, no packets are leaving the VM. I'll address that early next week.

Coming back to the MAC rewriting, that is working properly now after ironing a couple of mistakes I made in my code I found during testing.

Still need to design a way of getting client traffic to the router in it's own VLAN pair (for segregation), and then back again. The latter is the trickier part, I think.




Now that I have something that works with Q-in-Q, I've progressed on a couple of security considerations I've had in relation to MAC spoofing and keeping my L2 segregated.

I have functionality where the source MAC that gets handed to the RADIUS server is set by my controller, and maps back to an S/CVID mapping. When the traffic comes back, the original MAC is restored so the client doesn't get confused.

I am also considering having this same functionality with traffic going to a router.

I also need to figure out whether I will be passing both VLANs to the router, or none, or one, and how I will get VLANs back into the Handover Port.

Also fixed a "bug" where I didn't send packet_in's back out, so that's back in the code.




Built a de/muxer for VLANs. The only thing I don't like is if I attach my RADIUS port to a low port number, say, port 2, SVID 10 traffic will come out on port 11.

To counter this, I might statically reserve "special" ports, and then offset the incoming ports by that number i.e. reserve the first 4, and then anything I see come in will be off by 4. Doing this statically is a little tedious, but it's better than it not working at all.




Supporting Q-in-Q is hard apparently, the 'work' in workaround isn't a thing.

Have discovered a lovely behaviour where in the Openflow1.3 spec, ethertype should be able to be seen for frames after vlans. The plural is important, but what I'm seeing is that only the first two ethertypes get sent through, so matching on 0x0800 works for one vlan, but a second one makes it break. Need to decide whether we submit a bug report based on this finding. This was found in my testing environment and in hardware (pronto).

Table hopping doesn't work due to ovs and vswitchd not recirculating frames, a process where headers get sent to vswitchd, vswitchd does some work, throws it back at ovs to get the rest (done with mpls). Could hack ovs to make it do this, but not really a lot of point since it wont run on hardware. May change my mind on this.




REST API works a charm, freeradius can authenticate users and add OpenFlow rules to allow the customer to talk to a router.

VLANs are hard, it breaks everything and I'm yet to find a solution for this. Matching on 2 vlans is still not a thing and handling a single vlan, stripping it and throwing it at a second table doesn't work. It seems OVS can only process one VLAN per run through the switch, which sucks.

Talked to Chris at Lightwire about his solution, which is hack the code until it works. I'm probably not going to be able to get Lightwire IP out of him for the project, and it sounds hard. I'll have to come up with some other solution.




Got a little bit of work done this week. Have setup freeradius3 in a new deb8 VM, have bridged device to mininet test environment and can hand out DHCP leases without too much hassle. Currently, there's no VLAN tags on this otherwise it breaks, so need to investigate freeradius sitting on multiple vlans (vlan per hop) handing out DHCP to double tagged traffic (triple if you count the HOP vlan).

Also added rest api support to the controller, will build on that once I have the VLAN task sorted.




This week saw a good step in progress. I can connect a host, it achieve a DHCP lease and it can talk to a router. Beyond this, it should work, just need to get a VM running that has access to the interwebs, or run a webserver.

I will probably look at expanding my test environment to multiple hosts connecting to the HOP on different VLANs so I can start emulating a network as similar to a real ISP network as possible in terms of customer connectivity to the internet.

I have a few assignments due over the next couple of weeks, as well as the interim report so I'll probably focus on those until the end of the semester, or at least til study week when they're all due.




This week saw some good progress. I can successfully push rules to the switch and have traffic correctly flow through to devices. This saw the end of what my current testing enrivonment which so far was some simple mininet hosts sitting there waiting for something to happen.

I've spun up a new VM which has a tunnel between itself and the mininet VM, which I'm attaching to the current mininet topology in order to have more control over the host running dhcp, since we'll need to run OVS in front of this to deal with the triple VLAN tags according to Brad.

Currently this tunnel isn't working, which will be the next thing to fix. Once I have this running, spinning up a dhcpd and getting dhcp traffic back to the host asking for an address should be simple and said host should get an address.

Edit: I've since got this working today, error in my script in which interface was selected for the tap. Home time now.




Started making progress on the actual code behind the controller. So far I have it running, getting packets in and reading said packets. Ran into a bit of delay in figuring out how I'll create the rules since I started off by trying to create rules for DHCP communication, but since I don't know what ports on datapaths it's connected to to begin with, I need to learn them once I've started.

My initial thoughts are that I know the MAC/IP of my infrastructure that connects to the core switch, so I can create ARP packets, send them out the flood port and wait til I get a reply and handle them from there. Once I've done this, I can create the flows to allow DHCP traffic to get where it needs to go.

The next part is how does my controller know when a client is allowed to have internet access (Authorisation of AAA). I assume that one a client tries to talk to the WAN router, that information of where the WAN router lies has been given to them, so should be allowed to have access to it. The only problem here is that one could just know the configuration, set themselves up manually and go for it. I think this situation is okay for now, since this is less of a priority of getting things working in the first place.




Unfortunately spent most of my time on assignments as of late. The good news is that they went quite well, and I haven't got any to do for the next couple weeks, so should get some good development progress done.

Have also arranged weekly meetings with Brad.