Labels

[wol] Wake on Lan

wakeonlan client

On the computer you will use to send the WOL packet, you need to have a client to generate this kind of data. You may use net-misc/wakeonlan Perl script as client, which is in Portage tree:

emerge -n net-misc/wakeonlan

Prepare and wake up your PC

You need to know the MAC address of the PC you want to wake up; you may get this information from the client PC using ping towards the PC you want to wake up (in this example 192.168.20.52) and then you can see the arp table:

ping 192.168.20.52 arp

You will have an output similar to this, from which you'll get the MAC address:

Code:
Address                  HWtype  HWaddress           Flags Mask            Iface jupiter.home.net         ether   00:0C:6E:96:58:DE   C                     eth0 

Now, you may switch off the computer on which you want to try WOL. From the client PC, you have to send the WOL packet:

wakeonlan -i 192.168.20.255 00:0C:6E:96:58:DE

In this example, we send the WOL packet in broadcast to the subnet 192.168.20.x, using the MAC address we got before. Now, if everything is ok, you see your computer wake up magically!

WOL always enabled on shutdown

You may experience that, on next reboot of system, your PC won't wake up, even if you send WOL packet correctly from another box; this is due to the fact that the ethernet driver will lose it's previous configuration during boot.

A quick and clean way to get rid of this, and let the wake on LAN be enabled on every shut-down, is to add this line to /etc/conf.d/local.stop

Code: /etc/conf.d/local.stop
ethtool -s eth1 wol g

This is the same command used to enable WOL previously used from shell; when your Gentoo box turns off, the commands presents in this configuration file are executed, so you'll have WOL enabled at every shut-down.

[info] ASCII Table


[info] detect internet IP

http://ipid.shat.net/iponly/

this site can used in other program to detect external IP addr

[wireless]Wireless System overview

Wireless System

Wireless System Overview


Since ancient times, humans have learned to cooperate in order to overcome nature's limitations. There is a growing need to exchange information and services quickly and effortlessly across local, national and now global communities. People want the ability to communicate any time, anywhere in our mobile society.

Wireless technologies make our mobile society possible. Apple's iPod library syncs up with a laptop computer, drivers navigate their cars over uncharted roads, bargain hunters browse online stores, business travelers collaborate 24/7 with associates around the globe. Regardless of the circumstance, people today have an unprecedented level of mobility thanks to any combination of the four common wireless services:

1. WPAN: < 10 m, such as hands-free cell phones

2. WLAN: < 100 m, such as laptop to broadband access
3. WMAN: < xx Kms, such as building-to-building
4. WWAN: cell phones

In general, WLAN provides the most versatile service.  WPAN range is too short and still binds the user to the nearest node.  WMAN is too bulky and expensive to lug around. And WWMAN suffers speed and service charge constraints.

According to industry consensus, WLAN applications consist of three categories that cover many of our day to day mobility requirements:

1. PC Networking: Desktop Computers, Laptops, Routers, Printers, etc.

2. Consumer Electronics: Video Game consoles, Projectors, DVD players, TVs, Set-top boxes, Digital Cameras, Security Cameras, etc.

3. Handheld Devices: Mobile Phones, PDAs, iPods, Video iPods, etc.

In order to ensure high throughput, good range and universal interoperability, IEEE 802.11x standards govern WLAN operations. WLAN and IEEE 802.11x have become synonymous over the years:

  • IEEE 802.11 - The original 1 Mbit/s and 2Mbit/s, 2.4GHz RF and IR standard (1999)
  • IEEE 802.11a - 54Mbit/s, 5 GHz standard (1999, shipping products in 2001)
  • IEEE 802.11b - Enhancements to 802.11 to support 5.5 and 11 Mbit/s (1999)
  • IEEE 802.11c - Bridge operation procedures; included in the IEEE 802.1D standard (2001)
  • IEEE 802.11d - International (country-to-country) roaming extensions (2001)
  • IEEE 802.11e - Enhancement: QoS, including packet bursting (2005)
  • IEEE 802.11f - Inter-Access Point Protocol (2003) Withdrawn February 2006
  • IEEE 802.11g - 54 Mbit/s, 2.4 GHz standard (backwards compatible with b) (2003)
  • IEEE 802.11h - Spectrum Managed 802.11a (5 GHz) for European compatibility (2004)
  • IEEE 802.11i - Enhanced security (2004)
  • IEEE 802.11j - Extensions for Japan (2004)
  • IEEE 802.11k - Radio resource measurement enhancements
  • IEEE 802.11l - (reserved and will not be used)
  • IEEE 802.11m - Maintenance of the standard: odds and ends
  • IEEE 802.11n - Higher throughput improvements
  • IEEE 802.11o - (reserved and will not be used)
  • IEEE 802.11p - WAVE - Wireless Access for the Vehicular Environment (such as ambulances and passengers cars)
  • IEEE 802.11q - (reserved and will not be used, can be confused with 802.1Q VLAN trunking)
  • IEEE 802.11r - Fast roaming
  • IEEE 802.11s - ESS Mesh Networking
  • IEEE 802.11t - Wireless Performance Prediction (WPP) - test methods and metrics
  • IEEE 802.11u - Compatibility with non-802 networks (e.g., cellular)
  • IEEE 802.11v - Wireless network management
  • IEEE 802.11w - Protected Management Frames
  • IEEE 802.11x - (reserved and will not be used)
  • IEEE 802.11y - 3650-3700 Operations in USA

Among the physical layers, .11, .11b, .11a, .11g and Draft n offer progressive speeds over the course of development, which are as follows

Standard YearModulationPeak Rate Peak Throughput
.11 1999DSSS2 Mbps 1 Mbps
.11b1999CCK 11 Mbps 6 Mbps
.11a1999OFDM54 Mbps 25 Mbps
.11g2003OFDM54 Mbps 22 Mbps
Draft n 2006MIMO OFDM 300 Mbps 180 Mbps

Also available are security features vital to wireless protection; QoS support that improves the service quality when service compromise becomes inevitable; radar detection that avoids interference with airport or weather Radar operations.

Users should evaluate application needs carefully and tailor the product appropriately. A sample of video application requirements are listed as follows:

Application Throughput
SDTV5 Mbps
Cable Modem 6 Mbps
DVD 9.8 Mbps
HDTV12.9 Mbps
ADSL2+20 Mbps
FTTH 30 Mbps
HD DVD 36 Mbps
Blue-ray DVD 48 Mbps
VDSL50 Mbps

Video streaming is very demanding in frame errors, e.g., FER < 10-4 or tighter, so the peak throughput of a specific WLAN device is recommended to scale down to one-third of its original value for budgetary purposes. For example, a peak throughput of 15 Mbps is necessary for satisfactory SDTV streaming at 5 Mbps in general.

[cygwin]Howto make a portable cygwin environment

I, have thoroughly emigrated to Linux, need a Linux-Like environment
to make things better in my PC-Architecture course, so I decide to
make a portable cygwin environment.

Because I have no portable devices, such as Flash Disk. I have to
upload the whole environment to internet for further downloading.

Here is WHAT I do to make such a portable cygwin environment.

1. cp the cygwin which is already installed when I used windows to a
work directory named $cygwin.
2. write a script to make a cygwin environment, such as where is the
/, /usr and /bin in windows
use $cygwin/bin/mount to make mount points on which the
$cygwin/bin/bash depends to make a work environment.

/etc/profile will be read when evoke bash with a --login parameter,
namely evoke a login bash shell

[fpga] Storing Quartus II projects under version control

reference at nios2wiki



Storing Quartus II projects under version control

There is no need to backup all files in a Quartus project to be able reproduce it. You have to store source files (so that you can modify the project) and final binary files (so that you can reproduce the system exactly).

NOTE: This is not the final list yet, but it works for most simple projects (the software part is still missing). You should still test a reconstruction of the project from this files.

Quartus II source files:

  • project files:
    • project_name.qpf Quartus II project file
    • project_name.qsf Quartus constraint file (lists the hardware constraints defined for a project, from the used chip and pinout to timing constraints)
    • project_name.qws Quartus Window Settings ? (the configuration of the Quartus gui for the project, may be omitted)
  • top level source files:
    • project_name.bdf Block diagram / Schematic file (top level schematic file, there may be many nested files)
    • project_name.vhd VHDL file (top level VHDL file)
    • project_name.v Verilog file (top level Verilog file)
  • component source files:
    • component_name.bsf Block Symbol file (component symbol file)
    • component_name.vhd VHDL file (top level VHDL file)
    • component_name.v Verilog file (top level Verilog file)
  • SOPC builder project source files (SOPC builder creates many VHDL or Verilog files, that you do not need to store)
    • sopc_project_name.ptf the list and configuration of components selected in the SOPC gui
    • sopc_project_name.bsf Block Symbol file (SOPC component symbol file, especially if you modified it)
  • Board Description (if you created your own board, the list is incomplete!)
    • board_name/class.ptf
  • software source files:
    • tbd

Quartus II binary files

  • hardware binary files
    • project_name.sof SRAM Object File
  • software binary files
    • tbd

Reconstructing a project from a subversion repository

Since the subversion repository contains only the necessary files, a procedure should be followed for reconstructing the full project from the repository.

  1. Import the selected project from the subversion repository to the local drive.
  2. Open the project in Quartus II.
  3. Open the SOPC builder project and build it.
  4. Build the Quartus II project and program the hardware into the FPGA.
  5. Import the software part of the project into a NIOS IDE workplace.

References

Archiving SOPC Builder Projects http://www.altera.com/literature/hb/qts/qts_qii54017.pdf

[udev]Check cable status of LAN

To check carrier status

cat /sys/class/net/eth0/carrier

[info]rsync

Delta-transfer algorithm, which only transfers difference


[web]Download film directly using Wget

Ah oh,  my univ. has a VOD server, but we cannot download the movies that storage on it directly.

After sniffer some package,  I know how to download it

here it is

add a header to http request,

GUID: 00000000-0000-0000-0000-000000000000

and set user agent to

RMA/1.0

use wget to download it

wget -U "RMA/1.0" \
     --header="ClientID: WinNT_5.1_6.0.12.1056_RealPlayer_R30CND_zh-CN_686"
     URL


[linux] live CD/DVD Howto

Ref. at ubuntuforum.org


Background on live CD/DVD

Note: This section is a clarification of how live CD works. You don't have to read it. You can skip it if you want.

A live CD/DVD is basically a normal linux installation just like an ordinary harddrive installation. However, simply copying the harddirve installation over to a CD/DVD is not enough to produce a working system. Why? because there are still minor differences between a live CD/DVD and on ordinary harddrive installation. So in addition to copying our harddirve installation to the CD/DVD we must address those differences as well.

So what are these differences?
  1. The CD or DVD is read only media. Linux needs to have write access to certain parts of the system to be able to operate properly (like "/dev" "/proc" "/var" "/tmp"). There are a lot of approaches to address this problem. All of which utilize the system RAM. Some of these approaches enable write access only to essential directories and files, and hence, they do not allow the user to modify the system or install new packages while in the live CD. Other approaches, like unionfs which is what is used in this guide, allows the user to write to any part of the system. This is done by merging part of the RAM with the read-only filesystem of the live CD/DVD and making the look like one filesystem that have read-write access. Unionfs has to be mounted at boot in a certain manner.


  2. With the harddrive installation the location of the root filesystem is fixed. So it is passed to the kernel at boot time using the root=/dev/... parameter. With a live CD/DVD, the location of the root device is not fixed as the user might have multiple cdrom drives, these drives can be ide, scsi ... etc. So for the root filesystem to be mounted, there must be a way to identify the root device, and then we have to load the suitable kernel modules (to be able to access the cdrom controller as well as the CD filesystem). All this has to be done even before we have a root filesystem mounted.



  3. To fit on a CD, the filesystem is usually compressed using squashfs. So we need to autodetect the filesystem type. We also need to have the proper modules for mounting it.




These considerations require special preparation at boot time, some of which must be performed even before mounting the actual filesystem. How can we do this?

Linux introduced a mechanism that allow for such preparations at boot time before the actual root filesystem is mounted. It is called the initial root filesystem or initramfs. This mechanism is used also in mounting normal harddirve installations, as it adds flexibilty to the boot process.


initramfs is virtual filesystem. It is a compressed cpio (cpio is an archive format similar to tar) archive that contains a minimal shell, kernel modules necessary for mounting the root filesystem and number of scripts that perform some tasks at boot time. The most important of these scripts is a script called init located at the root of the initramfs.

How does initramfs work?

The boot loader loads both the kernel and the initramfs into memory and starts the kernel. The kernel then unpacks the initramfs and mount it as initial root filesystem, and then looks for the init program within the initial filesystem, and once it finds it, it executes it and hand the boot process over to it. This init scirpt is responsible for finding the real root filesystem and mounting it. It is also responsible for any special preparations required at boot time.

So any special operations required for booting the system from live media can be coded into the initramfs boot scripts.

How is initramfs is created?

We do not have to create initramfs manually (although it can be done). There are tools for creating and updating initramfs like the command update-initramfs. Moreover, these tools can include custom scripts into the initramfs if they are placed in a certain preset locations (/usr/share/initramfs/scripts). So all we have to do is dump our custom scripts (which will do all the required preparation for booting the live CD/DVD) into these preset locations, and then create a custom initramfs by running update-initramfs.

We don't even have to write these scripts. Why? becuase there are packages that have scripts tailored for booting form live CDs. One of these packages is called casper (this is the package used in this howto). By installing casper into the system, it places the scripts in there proper locations (where they can be spotted by update-initrfamfs). The only thing we need to do after installing casper is running update-initramfs to create an initramfs suitable for live CD/DVD.







The live CD/DVD structure:

The directory tree of the live CD/DVD we are going to create is going to look like this:

Code:
(CD ROOT)
|-------+casper
| |-------filesystem.${FORMAT}
| |-------filesystem.manifest
| |-------filesystem.manifest-desktop
|
|-------+boot
| |--------+grub
| | |--------menu.lst
| | |--------stage2_eltorito
| |
| |-------vmlinuz
| |-------initrd.gz
| |-------memtest86+
|
|--------md5sum.txt

  • /casper/filesystem.${FORMAT}: This is the container of the linux filesystem we are going to copy from our harddisk. It is usually a compressed filesystem like squahsfs.
  • /casper/filesystem.manifest: This file is optional. You only need it if you decide to include the Ubuntu installer in the CD. The purpose of this file will be explained later.
  • /casper/filesystem.manifest-desktop: This file is optional. You only need it if you decide to include the Ubuntu installer in the CD. The purpose of this file will be explained later.
  • /boot/grub/menu.lst: File containing boot options for the live CD/DVD.
  • /boot/grub/stage2_eltorito: The boot loader of the CD. (stage2 of grub).
  • /boot/vmlinuz: The linux kernel. This is copied form the linux filesystem.
  • /boot/initrd.gz: the initramfs that contain the customizations necessary for the live CD/DVD.
  • /boot/memtest86+: Optional file used to test the RAM of the machine form the live CD/DVD.
  • /md5sum.txt: Optional file containing checksums for all the files in the CD.

[info] use google to search locale related info.

 
where $locale is the abbrevation of locale. and the last slash is neccesary.
 
e.g.
 
search japanese
 
engliah
 
chinese

[info] skip the authentication of Computer Lib ,Ynu

when the system boot , there are two processes to check the validity of logon user.
 
remotecfg.exe and remoteAutoLoad.exe
 
this two procresses are interlocked, say that while we close one, the other will detect this behavior
and start it again.
 
Method to close both:
 
1 use debuger ntsd to stop one
2 close the other
3 close the debuged one
 
 
 
 

[info]Manipulating config file when programming

libconfig
libconfuse
lua