The big improvements is that you can compile Linux without the full MinGW/MSYS install by running the ‘blind’ script which will compile the kernel without make and friends.
The build process for the kernel works as well so now with the included Qemu 0.12.5, no need to link under Linux anymore. I fixed up some of the build processes as I thought I’d re-build and some stuff bombed so it’s all fixed up.
For those interested, I just updated the original download here:
It looks like in the wake of a declining stock price EMC/VMware is already laying off divisions, to ‘cut costs’ and I just received word from a friend that the “Hosted UI” group responsible for all these great products, and the former VMware Server/GSX products were all let go.
Which to me is kind of crazy as this eliminates the only desktop product that could run VMware ESX on the desk for building virtual clusters. I further guess it means that for what I like to do, I’ll eventually have to find one of those super expensive video cards that works with ESX to passthrough. Or just drop any and all VMware stuff, and head straight into KVM territory and just get used to OpenStack being a fragmented disaster.
So I had this fun episode where I was using Qemu to emulate an ASA, and it worked OK but it was incredibly slow, and I couldn’t put in multiple gigabytes of RAM. So I thought I’d just dump Qemu and load it up on VMWare.
Well simple ethernet connections work just fine, but the dot1q interface (as this setup has about 50 different connections) doesn’t work at all.
As I have attached previously there are 802.1q packets leaving the GNS emulated 7200 router but they are not being interpreted by the HOST-ONLY Adapter that is installed with workstation 11 nor does the HOST-ONLY adapter then TAG the l2 frames with the 802.1q ID.
So the host only adapters that I’m creating to give VMWare interfaces that GNS3 can latch onto, strip dot1q!
Well this is no good!
So I thought I’d try the older standby solution, which is the MS Loopback adapter, and try it that way.
Adding the adapter wasn’t too hard in 10, but they renamed it to the KM-TEST Loopback Adapter for some reason. Anyways with the adapter installed, I removed all the bindings other than the VMware Bridge Protocol.
With that done, the next thing to do was run vmnetcfg, and bind the tunnel interface to a VMnet interface but not in the Host-only connection but bridged directly to the loopback adapter.
Now with the VMware part configured, it’s a matter of configuring a Cloud object in GNS3, and binding it to the loopback adapter, which in my case has the great name of ‘Ethernet 2’.
From there I just attach the cloud to a dot1q ‘trunk’ interface on a GNS3 virtual ethernet switch.
With this proverbial house of cards built up, I can fire-up another VMware machine, in this case a Windows 2000 computer that is bound to a ‘normal’ VMnet adapter, with no fancy dot1a and..
Advanced engine needed : Limit-removing source ports
Primary purpose : Single Player, Co-op, Deathmatch
Title : Tech Gone Bad
Filename : e1m8b.wad
Release date : Jan 15, 2016
Authors : John Romero
Email Address : email@example.com
Others Files By Author : doom1.wad, doom2.wad
Misc. Author Info : My previous Doom levels were made in 1995 for The
Ultimate Doom (e4m2, e4m6), so this is a warm-up.
Additional Credits to : John C., Adrian C., Tom H., Kevin C., Sandy P., Dave T.
Pascal “CodeImp” vd Heiden for Doom Builder
The Doomworld Community
Linguica and J.P. LeBreton for Testing expertise
General Description : My Boss level replacement for e1m8…22 years later
After exiting the Computer Station you knew the worst was up ahead. You still hadn’t
reached the place where the demons were coming from. The steel door shuts
behind you as you realize you’re there; you’re at the Phobos Anomaly. Cracks from
hell are all over the place as seepage from the portal invades the entire installation.
Now it’s time to find the portal and stop the demons from coming through. You know
UAC had hundreds of scientists working at a high-tech lab somewhere in this area, and
the portal must be connected to it somehow. Time to lock and load.
* What is included *
New levels : 1
Sounds : No
Music : No
Graphics : No
Dehacked/BEX Patch : No
Demos : No
Other : No
Other files required : Doom1.wad or Doom.wad
* Play Information *
Game : Doom 1
Map # : E1M8
Single Player : Designed for
Cooperative 2-4 Player : Designed for
Deathmatch 2-4 Player : Designed for
Other game styles : No
Difficulty Settings : Yes
* Construction *
Base : New from scratch
Build Time : 2 weeks, in spare time
Editor(s) used : DooM Builder 2
May Not Run With : Doom2.exe
Tested With : ZDoom 2.7.1, Crispy Doom
Known bugs : No
* Copyright / Permissions *
Authors may NOT use the contents of this file as a base for
modification or reuse. Permissions have been obtained from original
authors for any of their resources modified or included in this file.
You MAY distribute this file, provided you include this text file, with
no modifications. You may distribute this file in any electronic
format (BBS, Diskette, CD, etc) as long as you include this file
intact. I have received permission from the original authors of any
modified or included content in this file to allow further distribution.
I tried it with DooM v1.1 and v1.9 and they both load up the level but at certain points may bomb out with a R_FindPlane: no more visplanes. So you’ll want to use ZDoom or Crispy Doom as indicated in the readme.
But for those who want vanilla, remember to load up the WAD like this:
DOOM -file e1m8.wad -warp 1 8
Or alternatively you can jump to the level by typing in idclev18
That is, add the option UseRoaming no to your /etc/ssh/ssh_config (or your user’s ~/.ssh/config) file, or start your ssh client with -oUseRoaming=no included on the commandline.
We will be updating this article with more information as it becomes available.
UPDATE: This affects OpenSSH versions 5.4 through 7.1.
UPDATE: The following commit from deraadt@ has just gone in:
Module name: src
Changes by: firstname.lastname@example.org 2016/01/14 07:34:34
usr.bin/ssh : readconf.c ssh.c
Disable experimental client-side roaming support. Server side was
disabled/gutted for years already, but this aspect was surprisingly
forgotten. Thanks for report from Qualys
UPDATE: Errata patches for 5.8 and 5.7 have been published.
* SECURITY: ssh(1): The OpenSSH client code between 5.4 and 7.1
contains experimential support for resuming SSH-connections (roaming).
The matching server code has never been shipped, but the client
code was enabled by default and could be tricked by a malicious
server into leaking client memory to the server, including private
client user keys.
<b>The authentication of the server host key prevents exploitation
by a man-in-the-middle, so this information leak is restricted
to connections to malicious or compromised servers.</b>
MITIGATION: For OpenSSH >= 5.4 the vulnerable code in the client
can be completely disabled by adding 'UseRoaming no' to the global
ssh_config(5) file, or to user configuration in ~/.ssh/config,
or by passing -oUseRoaming=no on the command line.
UPDATE: Fixed versions are available for OpenBSD snapshots dated 2016-01-12 and later. M:Tier has binpatches for OpenBSD 5.7-stable and 5.8-stable. Debian, Ubuntu, RHEL, and many other Linux distros have it now or will soon.
UPDATE: The roaming code has been stripped out of OpenBSD -current:
UPDATE: The FreeBSD port has been updated, but the version in their base system remains vulnerable.
UPDATE: Qualys Security has posted their full report on the issues.
UPDATE: While the information leak is much more difficult to exploit on systems with ASLR, like OpenBSD, some users may want to consider rotating their key pairs. If you use ssh-agent(1), however, the man page offers some good news:
The agent will never send a private key over its request channel. Instead, operations
that require a private key will be performed by the agent, and the result will be
returned to the requester. This way, private keys are not exposed to clients using the
UPDATE: For Mac OS X, the version of OpenSSH in MacPorts has been updated. Since Apple typically delays security fixes, you’re advised to apply the workaround if using the bundled OpenSSH instead.
I only have to wait 24,153,992 minutes to unlock my iPod! That is just under 46 years.
So I haven’t used this in a few months, and the battery went flat, but with iOS 9 or whatever this is running it reset to 1970, and now won’t let me even try to unlock it. Good thing the MacBook Air I sync’d it with is dead too. I guess that’s 2012 for me.
I just don’t want to hard reset it, so I guess I’ll have to see if there is a root kit/hack to set the clock.