I have a Cisco 2691 router running IOS 12.4 series at home currently, and I've been planning to cook up a VPN setup on it that allows me to connect back home, and also to "trombone" my way back out from home. I wanted toe setup to be as short and simple as possible, but still include encrypted communication. Finally, I wanted this to be available using "standard setup" client software on my XUbuntu+NetworkManager laptop, as well as Windows 7.
The "kicker" that made me finally cook this up, was the need to easily demonstrate to a colleague as well as a few students a simple way to do road warrior VPN using a Cisco IOS router as the termination point.
My setup uses Microsoft PPP Extensions to get encrypted communication, and as such it is a form of PPTP VPN.
The important bits to understand this setup is:
- I use the IPv4 range 10.0.5.0/24 (or rather a subset of it) for the VPN clients.
- VPN clients connect to my "Internet" facing address, located on FastEthernet0/0
- All my internal networks, including VPN clients, use NAT with overload (PAT) for IPv4 communication with "the world"
I suppose it should be possible to use a Mac as a client for this setup too, but to be honest, I can't be bothered to check
aaa authentication ppp VPDN_AUTH local
ip name-server 10.0.2.2
! Default PPTP VPDN group
username vpntest privilege 7 password 7 053D1601114D5D1A0E550516
ip nat outside
ip unnumbered FastEthernet0/0
ip nat inside
peer default ip address pool VPNPool
ppp encrypt mppe auto
ppp authentication ms-chap-v2 VPDN_AUTH
ip local pool VPNPool 10.0.5.2 10.0.5.31
ip nat inside source list NAT interface FastEthernet0/0 overload
ip access-list standard NAT
permit 10.0.5.0 0.0.0.255
I'm almost done putting together the new frame for my printer, but stopped to upload a short video, as seen above. I'm amazed at how much flex I've lived with on the old frame, and already really believe that I'll be getting better results with the new frame. Before, I could flex the frame on the corners by a few centimeters(!), the we one simply does not move. This gun' be gud'!
When I started experimenting with 3D printing, I did a bit of research on the alternatives, and the requirements for the various plastics. From that search, I figured that ABS would require "care", while PLA would be simple to get started on. I didn't really know how I would build my printer, so I settled for printing in PLA.
Generally, I've had good success with printing in PLA. The thing I've generally struggled most on with PLA is getting good, even extrusion. I would frequently get jams, extruder "rollback" or uneven extrusions. When I got successful prints, they have generally been OK looking, and I've always had good print adhesion. From my third print I've always done PLA directly on a 60ºC heated glass bed.
After my last post about the OCB project, I did a lot of building, and running the prototype. But I didn't post any updates during that time. The reason for that is that I really didn't have anything that I wanted to show. The initial buildup went fairly quick, I got decent speed out of the CoreXY mechanism, and I managed to print stuff. But I had some real issues that stopped me from saying "It works".
Please read on after "the jump" ...
I've used a wide range of GUI operating systems, and I'm not terribly fond of today's flat paper-style GUI's. And I keep thinking that we're a bit stuck on the window manager HCI that Bill &co invented in '95. I'm no graphics person, but tonight I started doodling on the window-manager decorations of something reminding me of the «Fischer Price» style of the late nineties. Maybe I'll expand on the idea? Maybe it'll end up with all the other unfinished ideas?
I've settled on "OpenCoreBot" as my working title for my 3D printer (as mentioned in the previous post). The project plan started when I was looking for already existing 3D printer projects in the open-source/open-hardware realm based around aluminium extrusion. I was also looking for a design that did not use the "moving y" concept, simply because of the experiences from my DIY mini-CNC router. Using slotted square extrusions in mechanical buildup of CNC equipment has been close to a norm a long time. This kind of construction gives some important advantages, among them high flexibility and rigid constructions. What I did discover when looking at existing designs, was that there were a few open-hardware friendly designs based on the Mendel and Prusa designs, but other non-moving-y designs generally did not use open components other than printed and motion-control parts.
I think I've arrived at a stage where I can show a bit of what I'm, working on, both as a teaser, and as a commitment for my self to make the teaser a reality ...
So, after several hours teaching myself Solidworks, I can show off the following image:
Working-name for the project: OpenCoreBot, or OCB. More details to follow when I'm closing on completion of the design.
After reviewing the naive errors in my thinking (see previous post), I've concluded that my idea for simplifying the belt path will not work. So, a revised prototype has been built, now using 3D-printed belt idlers on the loops, and only straight & symmetric lines on the essential parts of the belt path.
So, I'm no longer chasing the not-crossing belt path, instead going with a conventional, two-level CoreXY. There is now a crossing path on the belts, but the belts run on two separate levels, so there is no parts where the belt is forced to move in ways it's not designed to do.
After building my first prototype of a CoreXY based cartesian movement system, as shown in two earlier posts ((CoreXY Experimentation))((CoreXY experimentation update)), I have realized that my idea for a simpler pulley configuration is flawed. I've simply forgot basic geometry math. The idea was to start with a CoreXY system, as described on http://corexy.com, take inspiration from FABtotum to avoid crossing belts, and simplify the pulley location to get as few anchor poins for the belts as possible. My attempt used two "layers" of belt paths, and tried to reduce the number of pulley-axles to 4, compared to CoreXY's 8 and FABtotum's 6. But, unless I start offsetting the location of stepper motors (and introducing uneven stress on the frame), I end up with an undesired geometry...
This week I re-launched my blog, and I really wanted to do so silently, without the useless "Oh look, I've upgraded" type of post that so many publish (including myself in the past). But I was hit by a very common abuse-vector that prompts me to write a few words about it. The problem: DoS via WordPress XMLRPC. I've installed WordPress 4.0, a version where flaws in the XML-RPC mechanisms allowing it to be used as part of bot-nets and the like are supposedly resolved. But, after having my new WP installation active for less than 24 hours, my server ground to a halt, with ridiculous load numbers (190+ load), all caused by accesses to /xmlrpc.php
What is XML-RPC anyway?
The XML-RPC API is used by WordPress for a few things. The useful part, is making third-party publishing and administration applications for both desktop and mobile. But it is also used for so-called "pingbacks" and "trackbacks", where WordPress itself notifies other WordPress installations that links to their content has been created in articles/posts/pages. As this mechanism is supposed to run without user intervention, it's done without authentication, unlike the third-party client enabling admin/publish features of the API.
Insecure by default
Before WordPress 3.5, the XML-RPC API was something you had to actively enable. So to be able to use the API for publishing clients and/or pingbacks and trackbacks, you had to be aware of that the API existed, and enable it. For a number of reasons, I think that was a really good idea. Perhaps primarily because the XML-RPC used to have some seriously big flaws that could be used as vectors for abusing a WordPress installation. Now, from version 3.5, most of these flaws have been fixed. And with that, someone decided that users of WordPress are not very bright, and having to enable an API before using a third-party client was very complex and too hard for the users to understand. So they enabled the API by default. And removed the option for turning it off easily! How can possibly having an open API for anonymous, un-authenticated generator of HTTP-requests enabled by default, with no filtering, be a bad idea, right?