Archive for the ‘None IGEL’ Category

Tip: Wake on LAN/Magic Packet information collection and check list

Monday, January 21st, 2013

Hello,

very often i’ve been asked related to Wake On LAN and mostly people are not getting it to work. Please note: WoL/Magic Packet’s is a technology created by AMD and not IGEL!

Setting up WoL mostly requires good networking skills and the right infrastructure, so you have to figure this out: There is no “general” tip or configuration at all!

Here are some good 3rd Party information sources:

http://en.wikipedia.org/wiki/Wake-on-LAN (english)
http://de.wikipedia.org/wiki/Wake_On_LAN (german)
http://support.amd.com/us/Embedded_TechDocs/20213.pdf (AMD Tech Specs for Wake on LAN)
http://technet.microsoft.com/en-us/library/bb932199.aspx ( Troubelshooting WoL-Microsoft Technet)

Checklist for WoL:
1) In general make sure that WoL/Magic Packet’s are supported by “ALL” of your network devices like routers and switches.
2) Do not hard power off your devices (power disconnect), by definition WoL will not wake up a device after a hard power off!
3) WoL do not work thru WiFi (WoL is pre-WiFi time), for VM’s and/or devices with an Intel 10GB network card (not supported by Intel)!
4) Play around with the Wake on LAN configuration in the IGEL UMS Administrator or for Universal Desktop LX/OS you can also perform some configuration task thru System->Registry->network.interfaces.ethernet.device0.wol. Attention: Make sure what you’re configuring, otherwise the device will be powered on very often… 😉
5) Make sure the ARP cache/table (for Switches/Routers)  is large enough, typical symptom: Wake on Lan is working for a few hours after the device is (soft-) switched off, then it doesn’t work anymore from one second to an other. Cheap retail switches mostly provide a very limited ARP cache and/or high end switches needs to be configured in the right way to handle this.

Dealing with Wake on Lan is tricky and you should figure out which component’s are creating the issue but in 99,99999% it’s not the (IGEL) end device!

Cheers
Michael

Tip: Building a roaming WiFi solution with Thin Clients

Monday, December 17th, 2012

Hi Folks,

sometimes user try to setup a roaming solution together with Thin Clients and discover different connection issues and the roaming in general works bad.

Reasons for roaming issues:

– The WiFi Adapter is not designed for a roaming enterprise solution – This happens very often and mostly WiFi devices are designed for a stationary or home/office use where roaming is not required by default. This includes also the WiFi Adapter used in the IGEL extension food and nearly every WiFi Adapter sold at retail market’s.

– To small Antenna’s, a USB WiFi dongle comes with a 2 up to 5 cm (1 or 2 inch) antenna and this is in general no deal for a roaming WiFi connection. If you compare this to a Laptop antenna, which is very often 15cm or more included into the display part of an “enterprise” Laptop, it has no Chance to provide a good result. Retail home use Laptop’s do also mostly not provide a large antenna, this can be compared quite easy… Use a 600$ home and a 1300$ enterprise Laptop and compare the WiFi signal quality, in 80% of all test scenario’s you will see a big difference here and the enterprise Laptop provide a much better signal quality.

– Antenna is covered by parts of the device case and/or the signal is blocked in the direction to the Access Point.

How to solve this?

Simple: Forget WiFi network card’s or USB Adapter’s and take a new approach to setup a roaming solution: Use an Ethernet to WiFi bridge. This way is more expensive then a funny USB WiFi gimmick solution, but it will work and you have a lot of different solutions available depending on the scenario.

Benefit: The thin client/end device don’t has to deal with the WiFi connection at all, these device also do have more seperate antenna’s and very often more then one connection interface/circuit to provide permanent connection stability. It’s driver independent and it will work with Windows CE, Linux and Windows based end user devices out of the box thru the ethernet port.

Usage: Industrial WiFi requirements, Thin Client and WiFi device are mounted on a cart, truck, construction vehicle or similar. This solutions is not or only limited useable for regular Office walk thru designs.

Devices:

Netgear WiFi Bridge N900

From the lower price segment these devices will work good for small/medium environment’s: Netgear WiFi Bridge N900, Price ~100 US$, two antennas (picture) or Cisco Small Business – WET200 Bridge, Price ~130 US$ with two antennas. For outdoor solutions and high end requirements (large range/two or more connection circuits) the price range can go up to 1000 US$ or more. In any way: All devices that can be used as a WiFi Bridge (mostly all Access Points/Routers) can be used for this trick and they provide much better results then any WiFi USB dongle will do.

Update: I’ve been asked for an high end outdoor solution device, look @ Funkwerk/Bintec (www.teldat.de) for Bridge devices, the biggest devices can handle up to a 5km (4 Miles) distance and they always come with multiple circuits and antennas like the W1002n (up to 1000m range). But please: These devices are mostly not designed for indoor use and are very expensive (between 400 and 3000 US$)! So for industrial use in construction areas, mines or similar it might be ok but for the use in a habitation or indoor: Forget it please!!!

Cheers
Michael

P.S.: Like everytime no guarantee from my side and you need to test this! This article is also only for mobile clients moving around in a building or area a lot!

P.S.2: This will only provide a little help against radio interference, check this out too if the issue is not solved by an Ethernet to WiFi bridge! I’ve got an old  USB Bluetooth dongle that kills any WiFi (B/G/N=2.4 GHz) connection in a 5m (15 feet) area as example…. 🙂

USB Redirection and five things you should be aware….

Tuesday, September 18th, 2012

Hello folks,

very often users blame that “real” USB redirection doesn’t work well and they´re running in serveral issues. Some reasons why…

USB

1) USB Speed: If you are not using a zero client with a USB 1.1 port (i call it speed limitation on hardware level), the most important thing is “speed”. Don´t try to redirect a device that require 36mbit/s / 4,5mbit/s (Blue Ray Burner single speed) thru a 2mbit WAN connection… It will not work stable.

2) Voltage: If using an old USB Harddisk, use the right cable (Y-cable if needed) and make sure that the USB port can deliver the required voltage or use an active USB Hub with a seperate power supply. If you’re using a thin client which is a low voltage device, check this out first! Also do not use USB christmas gimmicks or USB coffee cup heater together with a thin client or any other low voltage device (tablet computer/netbook). Low voltage devices in general don’t provide a 450w power supply which is able to compensate this..

3) USB devices mostly require a “stable” network connection to be redirected, if this is not available.. Be prepared to have some fun with the users!

4) A USB device which is redirected to a virtual desktop or somewhere else can not be used with the local OS, this applies especially for keyboards, USB network devices and similar. Redirecting a USB WiFi device is a bad idea if you´re using this device also for the local network connection (connections loss after connection to the VM is established), redirecting a keyboard is a bad idea if you want to use it local (alt+ctrl+del as sample will be processed only in the VM and not at the end user device).

5) For IGEL devices: Enabling USB redirection in general will not redirect all connected usb devices, you have to allow it seperatly by class or device id to prevent issues mentioned in 4).

Cheers

Michael

P.S.: A small extension… Try to use “real” USB redirection only if you’re really need it! Very often there are more effective ways to use a USB device in a remote session thru virtual protocol channels like for audio devices, memory sticks, printers or smart card readers.