Showing posts with label Networking. Show all posts
Showing posts with label Networking. Show all posts

Monday, April 9, 2012

How to change Windows network location

Just found that one of my home computers using a static IP address was configured as “Public network” and for that reason not allowing access to shares. Although you can see from the screenshots is running Windows 8, I’m pretty sure the same works for Windows 7 as well.

Solution originally found here:
http://serverfault.com/questions/9376/is-it-possible-to-change-an-unidentified-network-into-a-home-or-work-netwo


Run Local Security Policy editor (secpol.msc) and navigate to Network List Manager Policies and find the network you want to change – for some reason, although the computer is wired, the network tooks the name of the router’s wi-fi SSID.


Double click the entry (Properties) and change location type – you can also change its name in there if you prefer (1st tab).


Refresh (F5) screen and voila, now I can just go and make sure file sharing is enabled for Private networks.


Sunday, March 4, 2012

Windows 8 Consumer Preview installation using Network Boot (PXE) - Update

An update to previous post explaining how to network boot using PXE. With Windows 8 Consumer Preview out, I’m back to trying to boot my old Vaio laptop using PXE and given Serva64 1.5.0 another shot.

It turns out that now running Windows 8 Consumer Preview on my laptop, both SolarWinds TFPTD and Serva64 were failing to serve files through TFTP to my laptop. Appears that the TCP/UDP Offloading were causing the issue, once turned off from my wired adapter, I could use Serva64 for both DHCP and TFTPD, simpler this way and using just one piece of software. I also changed from “PXE Compatibility” to “Option negotiation”, thanks to one of the comments on previous post (thanks Anonymous!).

Serva64 TFTP settings

Turning off all TCP and UPD Offload features from the wired adapter:

  • IPv4 Checksum Offload
  • Large Send Offload v2 (IPv4)
  • Large Send Offload v2 (IPv6)
  • UDP Checksum Offload (IPv4)
  • UDP Checksum Offload (IPv4)
  • UDP Checksum Offload (IPv6)

Network Controller - Advanced settings - offloading

Thanks to the Windows 8 feature that allows to easily mount ISO as virtual DVD drives, there is no need for additional software like Virtual Clone Drive and the such, I could just share the Windows 8 kit directly for remote install.

Windows 8 ISO drive

Saturday, March 3, 2012

Devolo dLAN 200 AVmini Starter Kit

Reading about power line communication technology a few years back when it was just a concept, I can see it came a long way and it seems quite mature now. Just bough this Devolo dLAN 200 AVmini Starter kit (2 adapters) to replace my wireless WDS setup (wireless router upstairs going through a wall and the floor to another router downstairs in the living room) - not necessarily to get higher transfer speeds, but to improve latency. I was annoyed at times when playing on Xbox Live and getting killed when I thought I got a swipe at the other guy to watch the replay later to find out that it wasn’t like that at all. I can see now a good improvement with the Devolo dLAN 200, although I guess the rest is up to me :-)

I had the kit installed for a couple of weeks now and fairly happy with it – very easy to connect, just plug in and devices will find each other quickly and you have a network in only a few seconds. The units seem to consume little power (~4 Wh), and they are smart enough to sense when the device connected to them is power off and will switch to power saving mode, pinging for activity every couple of seconds.

One device is plugged upstairs into my Linksys WRT54GL wireless router, and the second one downstairs plugged into a mini-switch, servicing both the Xbox 1 and Xbox 360. Both units are powered through extension leads, cause I don’t have enough power sockets on the wall, although Devolo recommends not do that, and for good reason as you will see, the performance is poorer that way. You can find units with pass through power socket to solve that issue, but didn’t want to pay extra really cause I thought I won’t really need it.

Here is the performance test with both units in extension leads – transfer speeds at around 4.5 MB/sec.

Copy transfer - extensions

Devolo Cockpit - extension

Running the test again with both units connected directly to wall sockets almost doubles the transfer speed at around 7.7 MB/sec.

Copy transfer - wall

Devolo Cockpit - wall

Personally, I don’t mind the transfer speeds so much, I don’t transfer a lot of files around to my Xboxes, and Xbox Live and Internet access seems to be faster than my old 802.11g WDS setup, so I’m reasonable happy with it, cause latency seems to have improved a lot. On the other hand, I guess if you are streaming HD content or wanting to transfer large files across the local network fast, you might not be too excited about it.

One other thing I found, and this is about the Devolo Cockpit application (screenshots), which you only need to review and configure the units, might consume a considerable amount of CPU (devolonetsvc.exe) – I did contact Devolo Support and they came back quickly enough, explaining what the service is used for and that it can be set to manual and stopped as it’s not required for the units to work.

Sunday, October 16, 2011

Windows 8 Preview installation using Network Boot (PXE)

Having an older Vaio VGN-A115B laptop with not enough disk space on the system partition (running the setup.exe from the older OS it says it requires 16 GB  free, although it will happily install later on a 12 GB partition), a shot DVD drive that couldn’t read a DVD-RW disk with Windows 8 installer and on top of that didn’t seem to power the USB ports at boot, the only option I was left off was to do a network boot (PXE) – something I always wanted to try. So after two days and a lot of failed attempts, here it is.

Somehow I always thought booting through PXE would be easy (just as easy as the USB or DVD boot) – and how wrong I was, as it requires both a DHCP server that allows to specify a boot program and TFTP server, neither of which is easily found on the net (details on Intel Boot Agent).

Eventually I did stumble onto TFTPD32/64 and Serva32/64 – both looking fairly similar which is fair enough cause the second is based on code from the first one. They seemed to have done the job well for other people, but for me the embedded TFTPD server failed a lot on transferring the BCD store during tests with a local VM, so I finally stopped using that and eventually found SolarWind TFTP Server much more reliable.

To make things even more complicated, you have to prepare the boot image with Windows PE (Preinstallation Environment) – you can find a lot more information for that one the web, but it does require quite a large download of the Windows Automated Installation Kit (AIK) – in my case I downloaded version 3.0 for Windows 7.

A few things to note about my setup

Since I already have a router on the network with a DHCP server running, to avoid conflicts I used an Ethernet hub I had around to connect the two laptops directly. I manually setup the Ethernet adapter on my “server” to use 10.0.0.1 IP address (easier to type) and disabled the firewall as well as the wireless adapter for the duration of the exercise (you can probably just as easily add the server programs below as exceptions to the firewall) – if you do it like me, remember to re-enable the firewall back on when finished and to set the Ethernet adapter for automatic IP allocation later on.

You may also notice that I also configured the DHCP server to server IP addresses from the same private class (10.0.0.xxx).

To point out we will prepare a 32 bit WinPE image in C:\WinPE directory and then use the C:\TFPT-Root\Boot to place the boot files (SolarWind TFTP server defaults to C:\TFTP-Root, feel free to change).

Windows PE image preparation

Installing Windows Automated Installation Kit (AIK) is fairly straight forward so I’m not going to go into details on that. For preparing the WinPE image I started from this Microsoft Walkthrough: Deploy an Image by Using PXE although I’m not going to follow it to the letter, feel free to use that if you want.

Run Windows AIK Command prompt:


Run the copype.cmd command (will automatically change to the image directory and will use relative paths from then on) – remember I’m building an image for an x86 system :
copype.cmd x86 C:\WinPE

imagex /mountrw winpe.wim 1 mount

copy mount\Windows\Boot\PXE\*.* C:\TFTP-Root\Boot

Now for copying boot.sdi you can use the full path to AIK tools or simply close the console and run a new Deployment console and use relative paths.
copy x86\boot\boot.sdi C:\TFTP-Root\Boot


Back to the WinPE directory and unmount the image (cleanup).
cd /d C:\WinPE      
imagex /unmount mount


Copy winpe.wim in the TFTP boot directory as boot.wim (might just work as winpe.wim, but the BCD commands below will mention boot.wim).
copy winpe.wim C:\TFTP-Root\Boot\boot.wim


Now moving on to preparing the BCD store. You might notice that instead of specifying the full path to the BCD I will change directory to the Boot directory and do it from in there. Personally I reuse the previous command (press up arrow) and change the parts at the end.
cd /d C:\TFTP-Root\Boot      
bcdedit -createstore BCD

bcdedit -store BCD -create {ramdiskoptions} /d "Ramdisk options"      
bcdedit -store BCD -set {ramdiskoptions} ramdisksdidevice boot       
bcdedit -store BCD -set {ramdiskoptions} ramdisksdipath \boot\boot.sdi

bcdedit -store BCD -create /d "MyWinPE Boot Image" /application osloader


Note the highlighted GUID value – you will need to copy that and use it in the subsequent commands (replace {guid} with the one generated for you).
bcdedit -store BCD -set {guid} systemroot \Windows      
bcdedit -store BCD -set {guid} detecthal Yes       
bcdedit -store BCD -set {guid} winpe Yes       
bcdedit -store BCD -set {guid} osdevice ramdisk=[boot]\Boot\boot.wim,{ramdiskoptions}      
bcdedit -store BCD -set {guid} device ramdisk=[boot]\Boot\boot.wim,{ramdiskoptions}

bcdedit -store BCD -create {bootmgr} /d "Windows BootManager"     
bcdedit -store BCD -set {bootmgr} timeout 30      
bcdedit -store BCD -displayorder {guid}

This is what I eventually got in the Boot folder.


Sharing Windows 8 installation files

    As you will see later on, when the remote computer will boot up and load the WinPE image it will take you to a command line where you need to map a network drive to the computer sharing the image files.

    In my case, I took the Windows 8 ISO image, mounted in Virtual Clone Drive and shared it as Windows8 folder. I also created a pxe user with pxe password (you can use an existing user if it has a password assigned to it), and you will see how you will need to map a network drive from the remote computer to the installation files in order to start the actual Windows setup.

    Serva32/64 DHCP server

      As noted below, I will configure Serva64 (in my case again, running Windows 7 x64) to only enable the DHCP server and disable the other services.
      IP pool / size : 10.0.0.100 / 100 (IP range .100 to .200)
      Boot file      : Boot\pxeboot.com
      Subnet mask    : 255.255.255.0

      SolarWinds TFTP server

        Not much to configure there, go to File > Configure and start the service (change the storage location to point to your files – note we’re not pointing to Boot, but the parent directory). Otherwise the software is smart enough to bind to the interface and allow to serve files.


        Test run with Windows Virtual PC

          Simply create a VM with a blank VM and it will try to automatically boot from the network – if everything works fine you will notice that it gets an IP in DHCP server console and it will start transferring files from the TFTP server.



            Old laptop (PXE booting)

              I should note that in the case of my VAIO I had to enable the Network Boot in BIOS (press F2 at boot) and then press ESC to get the boot devices listing and choose Network Boot. Then it will move to a screen similar to the above if everything is setup ok.

              Pressing F12 will continue the boot process, where it downloads the boot manager, WinPE image etc. Ignore the errors in the TFTP console about not finding boot.ini and wgl4_boot.ttf.


              Eventually the remote computer will start loading boot.wim and get you the setup background and a command line prompt. Now you will map that network drive to point to the installation files (remember I created a new user pxe/pxe and shared the Windows8 installation files – the net use command will fail if a user is not specified saying something about Server service not being started).

              From the remote computer console run the statements:
              net use y: \\10.0.0.1\Windows8 pxe /user:pxe
              y:\setup.exe
              And finally now you are running the Windows 8 setup and continue with the usual stuff… It only took me 2 days to figure it out and get it running, hopefully this is going to useful to someone else as well, I know I’ll definitely try it again, although I will be zipping up the boot files and keeping them for future use, what might change is the setup files on the share.

              Keep in mind that when we prepared the image in the first place it was for an x32 platform and you will probably need to go through the process again to build for an x64 platform, replacing all the x86 references with amd64.

              Sunday, January 24, 2010

              My Linksys WRT54GL router WDS setup

              wrt54gl

              After 3 years (almost on the day) of happily using my WDS network using two 3Com routers, one of them decided to send it’s last wireless packets in the ether and go to a better place (not yet actually, I’m still looking for a WEEE recycling centre in my area :-)

              Looking for a new router that supports WDS, not yet prepared to move onto 802.11n land, I stumbled onto a page on DD-WRT website saying that Linksys WRT54GL supports WDS if upgraded with the DD-WRT firmware. Always willing to try a bit of a hacking myself every now and then, that sounded very interesting.

              Got the Linksys WRT54GL v1.1 from Komplett.ie for a reasonable price, gave it an initial run to see that it’s working properly on it’s own and not DOA, then went along to flash the unit with the DD-WRT firmware.

              There are a few different firmware around for the Linksys router, it just happens that the first article I found on the WDS was written using DD-WRT, it looked good and that was it.

              Now, if you do make the same decision, do take the time and read a few articles on how to replace the firmware on the unit, follow closely the FAQ instructions on DD-WRT website and maybe this post in particular – otherwise you might find yourself with a fairly expensive paperweight.

              First check the router and hardware version in the DD-WRT database and pick the right firmware. I chose the 2.4 SP1 stable as the idea of trying out a beta version to start with wasn’t very appealing, but apparently 2.4 SP1 is quite old and has a few bugs (I found some of them myself later on), but definitely most important is to choose the one that says “for initial flashing over the WEB”. Before doing the firmware upgrade is best to reset the router settings (see the recommended post above) and then load the new firmware and do follow the instructions and wait for the 2 minutes recommended on in the firmware instructions. Best to do the firmware upgrade through an Ethernet connection rather than wireless, probably to avoid disconnecting in the middle of the firmware upload and bricking the unit.

              dd_wrt_database 
              Now, the new firmware is a huge difference to the factory Linksys firmware, it has so many options that I spent about a half an hour in the options trying to get my 3 computers wirelessly connected to the router and the internet, all looking good (this is when I found that with 2.4 SP1 didn’t assign correctly fixed IPs to the wireless clients based on MAC, but didn’t matter, went back to the manual IP assignment I had before).

              I configured the router with WPE security as my old 3Coms only worked with WPE in WDS mode, and now a week after, happy that the router works fine on it’s own, decided to keep the Linksys as the Internet router and configure the old 3Com OfficeConnect Wireless 11g Cable/DLS router (3CRWE554G72T/3CRWE554G72TU) as the WDS client / living-room router.

              The 3Com used to be my Internet router before so I had to disable certain settings like DHCP server and remove things like the port forwards, which I configured earlier on the Linksys router. Best to configure the secondary router through an Ethernet cable, while when needed, disabled the Ethernet connection and enabled the wireless connection to the Linksys to get / set settings required for the WDS. Also, to prepare for the link, I setup a different IP address on the 3Com secondary router.

              For WDS to work, both routers have to be configured with the same wireless settings (SSID, channel, encryption, wireless security) and setup the MAC of the other unit in the WDS page on each router.

              Linksys WRT54GL (Internet router, 10.0.0.1) – Wireless mode = AP (see the help link on the right on the web interface, it explains that).

              dd_wrt_wireless

              … and in the WDS page add the MAC address of the secondary router:

              dd_wrt_wds3Com 3CRWE554G72T (secondary router, 10.0.0.2) Now, to make the similar change in the 3Com WDS…

              3com_wds

              Remember, the key thing to remember is that the wireless network has to be configured the same on both routers, otherwise WDS will not work. Also remember to disable DHCP server on the secondary router otherwise you will run into problems. Also you can disable the stateful firewall on the secondary router since it’s not the internet router anymore (remember the old post where I had to disable the SPI anyway, otherwise Xbox 360 wasn’t connecting to Xbox Live). I also disabled the SSID broadcast on the secondary router, as I wasn’t going to use it as an access point, but only to forward the Ethernet connections for my Xbox and Xbox 360.

              That’s it for now folks, I’ll see how Xbox 360 works with the new setup later on, but for now the old Xbox connects just fine, well done, now to enjoy a well deserved break…

              Friday, January 19, 2007

              Wireless WDS link

              I have succeeded recently to create a WDS link between the two 3Com routers I had around, and I thought I might share the experience with you guys, as it took me a while to get this to work.

              The first router I bought a couple of years ago was in fact a 3Com OfficeConnect ADSL router (3CRWDR100A-72), and obviously I got it because I had an ADSL connection at the time. One thing that I liked was that it supported WDS, although I didn't have a use for it righ away, I thought it might come handy someday (and you will see, it did :-)

              Last year we moved in our own house and one thing I was looking forward to was to get NTL internet cable, available in the area. Since the old router wasn't going to work with the cable, I bought another one, and I did go for a 3Com again, the OfficeConnect Wireless 11g DSL/Cable Router (3CRWE554G72T). Again, the new router had support for WDS, and it looked like a nice feature to have, as I was thinking that I could connect the two of them if needed.

              As I had setup my desktop computer in the small bedroom upstairs, now converted to my own office (yeah!), I asked the cable guys to set up the connection up there as I wanted to have low pings on the net for some online gaming. My wife's Vaio notebook would connect wirelessly from anywhere around the house, so the whole setup made sense.

              Recently we've managed to furnish the living room downstairs, and now I could finally bring the TV and the Xbox downstairs, but the question was how to connect the Xbox to the Internet. I looked around for a wireless gateway to be able to connect the Xbox to the wireless router, but I haven't found one for a good price, and then I remembered about my old ADSL router lying around...

              As this was an ADSL router, I didn't have high hopes for it, as I was worried that the router would only know to route packages through the dynamic routes created when it connected to the PPPoE server through ADSL. I read up a few articles on the Internet, and the first attempt failed miserably, later on realizing that I was trying to use WPA encryption on both routers, as they were configured when they were used on their own.

              I dropped the idea for a while, and decided to get one (or even two) of the new 3Com routers that claim to support WPA over WDS links. I read some more, and I decided to give it another shot, this time starting with no encryption. As one of the articles suggested, I got my 8-port ethernet hub from the old stuff (but always useful ;-) pile, and wire in the two routers and the desktop.

              I started by disabling the DHCP servers on both routers, set-up static IPs on the routers as well as on the desktop, to avoid any issues involving DHCP - all IPs were in the same private class (10.xx.xx.xx). I also disabled the NAT support from the ADSL router, as the NATing was going to be performed by the cable router. I configured the routers to use the same wireless channel (the SSIDs do not have to be the same), enabled WDS support, configured the MACs for WDS on both routers and as soon as I saved the configuration, the lights on the hub started blinking quickly, as one of the articles said it would happen, because the packets were going in a loop from the wired connection, through the wireless, and then back through the wired connection. Hurray, there was hope that all the work wasn't in vain!!! I re-configured the routers to use WEP-128 encryption, lights blinking happily, even better news! Tried it once just for the sake of it with WPA-PSK, no sign of life, but I felt happy enough to go back to WEP and try the hole again, this time from downstairs. I decided to stick with the static IPs, plugged-in the Xbox, set the IP and voila, Internet through the wireless WDS link! Now after the couple of hours spent researching, trying, failing and then trying again, we finally deserved a nice long sleep :-)