Friday, December 28, 2007

Install Yahoo Messenger on Ubuntu

taken from forum by t1nt1n
December 17th, 2006, 11:55 AM
1. user$sudo apt-get install alien #install's alien to convert rpm packages to .deb#
2. user$sudo apt-get install libgdk-pixbuf2 #a package needed by messenger#
3. Download the following - rh9.ymessenger-1.0.4-1.i386.rpm from here -
4. user$sudo alien -c rh9.ymessenger-1.0.4-1.i386.rpm #converts it to a debian package#
6. user$sudo dpkg -i ymessenger-1.0.4-i386.deb #installs the package#
8. user$ymessenger #starts yahoo messenger#

Tuesday, December 25, 2007

Changin Endian to IPcop BOX

Since i have change my default gateway a week ago, my internet getting slow. EFW-2.2-Beta1 was installed on P3 128MB of RAM 6GB hardisk.

previously It was IPCop Box, because of some filtering not work as good as endian i change hardisk and install EFW-2.2-Beta1 in separated disk. but to day i feel internet slower than using IPCop.

finally i change hardisk with IPCop installed. some bios configuration was change so it become so weired,
there is no monitor in this box.

I guest should press F2 for continuing w/t new hardisk, and I'm lucky it work than IPCop was up.

( the correct one is press F1, it known after i retry again last night)

I realy surprised when i download same file and speed increase upto 2 times, even filtering not so good but it better for my internet caffe.

dev-NET now run IPCop for default gateway and Proxy.

I conclude that ipcop using squidguard may it lihgter than endian using Dansguardian.

Have nice holiday

Monday, December 24, 2007

HOWTO Building a Wireless Access Point

HOWTO Building a Wireless Access Point

From Gentoo Linux Wiki

Jump to: navigation, search

This article is part of the HOWTO series.
Installation Kernel & Hardware Networks Portage Software System X Server Gaming Non-x86 Emulators Misc

Please format this article according to the guidelines and Wikification suggestions, then remove this notice {{Wikify}} from the article

WARNING: This page needs a bunch of work! Although I've started making this article less specific to the Prism54 cards by separating out the first section, I haven't gotten around to doing any of the later sections yet - they need the Prism54 commands separated out from the generic bits, and stuff for the other cards added. Please help improve this page - if you're trying to get any other cards running as a basestation under Gentoo please feel free to make any appropriate edits. Email me if you'd like any help - if you're in the middle of a new build you should probably remind me that I thought it would be a good idea to give you my IM details so I can respond quickly.

If you have any comments or suggestions, feel free to email me.



[edit] Purpose of this Document

Many drivers these days automatically create an Access Point, but some will need to create their own if they have to use an older driver or if they want to use multiple Access Points. The Access Point also called in some places the "Interface" is the client, software created, viewport to a wireless network. It is necessary to have one to connect wireless network (Station).

[edit] Buy a wireless card that supports "master mode"

What we need for a wireless "base-station" or "access-point" is a wireless network card that does "master mode", which allows our Linux box to behave just like products from the likes of Linksys, Netgear & Belkin - later sections of this HOWTO should be pretty much the same whether you can find a 802.11a, 802.11b or g card that does master mode in Linux.

Do be careful when buying a card for this project - WLAN cards documented as Linux-supported often become no longer available and it's not uncommon for manufacturers of wireless cards to sell completely different cards with a completely new chipset under the model number of a card that is already currently sold. I guess this saves them the trouble & expense of having new packaging & advertising printed, but it causes copious confusion for the Linux-loving enthusiast. Also look out for D-Link's evil naming conventions - the 3 different revisions of the DWL-520 are all different from the DWL-520+, which is different from the DWL-G520, which is different from the DWL-A520 and so on... when you throw into the mix the 8 different cards with "DWL" and "650" in their names it can give you a headache just trying to work out which one your supplier is listing, never mind installing the drivers.

[edit] Prism (HostAP)

Note that cards using these drivers are 11MBPS only.

Jason Boxman provides quite an excellent description of these drivers:
HostAP enables 802.11b access point functionality utilizing the secondary (STA) firmware of Intersil's Prism2, Prism2.5, or Prism3 chipsets for time sensitive tasks. All other functionality is handled via the driver, including WEP and passing frames off to a port authenticator, like FreeRADIUS. Presently, HostAP works with Intersil's Prism chipset and cards utilizing PCI and PC Card interfaces to the host system. (PLX bridging is also supported)

[edit] Atheros (Madwifi)

Atheros chipset cards can use the MadWifi drivers and tools. After making sure that you have the appropriate kernel support for wireless (not any particular chipset drivers), emerge the madwifi-ng package.

Code: Installing Madwifi driver
# emerge madwifi-ng

The card will enter standard mode by default, but you want to bring the driver up in master mode. To accomplish this, you need to edit the module options. Note that the default behavior of etc-update will be to remove this customization, so remember to do what is necessary to keep your changes after re-emerging madwifi-ng (say, after a kernel compile).

File: /etc/modules.d/ath_pci snippet
options ath_pci autocreate=ap

Code: Updating modules
# update-modules

This is the old way of setting Atheros-based cards into master mode:

Setting the driver into master mode is not done in the standard way; you have to take the interface down, destroy it, and rebuild it in the new mode, which goes by the name 'ap' rather than 'master.' Here's how that works:

  ifconfig ath0 down
wlanconfig ath0 destroy
wlanconfig ath0 create wlandev wifi0 wlanmode ap

You could also skip the 0 in the last command, as wlandev will choose the first available integer if none is supplied. The benefit of this tool seems to be that you can create an arbitrary number of virtual ath interfaces, which could presumably be used to service multiple seperate lans with different access control and/or features. In any case, once you've created the new device in mode 'ap' you should see it in the output from iwconfig and it should say "Mode:Master"

Note that in all the rest of the configuration you should use the 'ath0' device, rather than 'wifi0' which appears to just be a container for the rest of the stuff.

This is all just what I've learned trying to set mine should probaby go to and read through their wiki and userdocs.

Tip: If you get the error "Could not connect to kernel driver" (when trying to start hostapd) look in your hostapd.conf if you have enabled encryption because if you haven't the interface isn't started correctly. For details: Madwifi Trouble Ticket.

[edit] NDISwrapper

NDISwrapper cards are NOT SUITABLE for base-station use - they don't do master mode. NDISwrapper is basically a layer of interfacing glue to use Windows drivers with Linux, and so it denies access to some of the more interesting &/or esoteric functions of the wireless card (because NDIS has no programming interface for them, I guess).

If you have a wireless card that you're currently using with NDISwrapper then it's possible that there are native drivers for it - I've seen quite a few posters to the Ubuntu forums suggesting using NDISwrapper with Ralink cards, for instance - but it's more likely that you'll have to bin it (or put it in your sister's Windows PC) and get a card with native drivers that interface properly with the kernel. NOTE: You can accomplish a similar goal with an Ad-Hoc network; this might help.

[edit] Prism54

I wanted a card that supported the Prism54 drivers, as they seemed to be about the most mature ones for "54G" wireless cards under Linux at the time I was looking - my Powerbook has Airport Extreme, Apple's name for 802.11g, so I might as well make use of it. I took a good look through the supported cards and decided upon the Allnet ALL0271. It seemed to be fairly well-recommended on the forums - there are too many short comments saying "worked for me" for me to post all the individual links, so do a search & read all the threads for yourself.

You can order the ALL0271 from the US, from Germany or if you're in the UK, I actually bought a handful, so email me if you'd like to buy one. I also recently got one of these cards working on a friend's SuSE 9.1 box, although the process isn't as brain-dead as it is under Gentoo - portage & the ebuilds automate the process so well.

[edit] Ralink rt2400 / rt2500

As I see on the rt2x00 project page, the new branch rt2x00 beta drivers support master mode and all advanced features, but legacy rt2400, rt2500, rt2570, rt61 drivers do not, but I have no way to test such setup.

For more details on this driver see the project homepage.

[edit] Broadcom 43xx cards (bcm43xx.ko)

Broadcom cards support master mode using the reverse-engineered kernel driver. You need to enable (or make as a module) the Softmac wireless extensions and BCM43xx wireless driver.

[edit] Realtek RTL8180 cards (rtl8180-sa2400 project)

Master mode is working correctly together with promiscuous mode, but there are problems with Wireless Extensions with version available in Portage together with kernels >=2.6.19 and the card may be handled incorrectly by init scripts. Supports WEP open encryption and possibly TKIP/CCMP(not tested). Broken with new(2.6.20+) kernels. Supports only 1/2/5.5/11M modes.

[edit] Texas Instruments ACX100/ACX111

In cards based on this chip (ex. D-Link DWL-520+) master mode is not fully implemented (as of 2007-01-01 driver) and there are some different problems like sometimes no beacons are broadcasted and card can't be properly initiated. Supports 1/2/5.5/11M(b) and 22M(b+) modes.

[edit] Intel PRO/Wireless (ipwXXXX) series

For ipw2100/ipw2200, unfortunately there is no way to use them as AP, but this can be done for ipw3945 and ipw4965, maybe ipw2915 too, which are pretty good cards anyway, using fully open-source iwlwifi drivers, but it can't be done with old Intel drivers with closed microcode.

[edit] Build a base Gentoo system

I'm assuming you've built Gentoo before - I just followed the Gentoo Quick Install Guide.

In order to run your WiFi drivers you need a couple of options enabled in your kernel, so you might as well do this during your original build. Look for:

Bus options (PCI, PCMCIA, EISA, MCA, ISA) --->
Support for hot-pluggable devices

CONFIG_FW_LOADER: m/y (either one will work)
Generic Driver Options --->
Hotplug firmware loading support

Device Drivers --->
Networking support --->
Wireless LAN (non-hamradio) --->

This is because:

from /usr/src/linux/drivers/net/wireless/Kconfig

Saying Y here also enables the Wireless Extensions (creates /proc/net/wireless and enables iwconfig access). The Wireless Extension is a generic API allowing a driver to expose to the user space configuration and statistics specific to common Wireless LANs. The beauty of it is that a single set of tool can support all the variations of Wireless LANs, regardless of their type (as long as the driver supports Wireless Extension). Another advantage is that these parameters may be changed on the fly without restarting the driver (or Linux). [This is handy for wireless PCMCIA (PC-) cards]

Now it's time to find and enable your drivers.

To determine type of your card,
emerge pciutils if you haven't done before,
and lspci.

You'll have to look under Wireless LAN category mentioned above, or in the portage, in the net-wireless category. Sometimes, when you choose to use driver from kernel, you should also pull in firmware for your card from portage, but not for every card.

To install in-kernel driver enable it either statically or as a module, by pressing y or m over desired item, then recompile and install new kernel or kernel modules.

If you want to use driver outside of kernel tree, proceed to next section.

[edit] Emerge the nitty-gritty

If you want to use driver outside of the kernel tree, you'll have to find it in portage, for example:

cd /usr/portage/net-wireless
emerge acx # replace acx with your desired driver name

Some of driver package are available only with testing keyword, others (ex. rt2x00) require setting USE flags. In that case:

mkdir /etc/portage # If you haven't already done so
echo net-wireless/rtl8180 ~x86 >> /etc/portage/package.keywords # To set the testing keyword
echo net-wireless/rt2x00 rt2500 >> /etc/portage/package.use # To set right use flags

Of course replace package names, categories and use flags with ones you need.

Finally, if you don't use coldplug or udev coldplugging, and you want your driver to be loaded at startup, add right module to right file in /etc/modules.autoload.d/.

The ebuild is clever enough to pull in everything else it needs:

  • wireless-tools - uh, what it says. Remember the bit in /usr/src/linux/drivers/net/wireless/Kconfig about "a single set of tool can support all the variations of Wireless LANs"?
  • hotplug - needed to "upload the firmware to the NIC's ram on initialization"

So now you're ready to go. Neither of the above should be masked, but if they are add them to /etc/portage/package.keywords the same as you did for the driver itself above. If you've chosen just to use the drivers supplied with your kernel then you'll need to emerge these two ebuilds separately.

[edit] First tests - checking your wireless card works

[edit] The technical way:

Code: Checking the card is recognized with iwconfig
# modprobe -v prism54
insmod /lib/modules/2.6.8-gentoo-r3/kernel/drivers/net/wireless/prism54/prism54.ko
# iwconfig
eth0 no wireless extensions.

lo no wireless extensions.

shaper0 no wireless extensions.

dummy0 no wireless extensions.

eth1 NOT READY! ESSID:off/any
Mode:Managed Channel:6 Access Point: 00:00:00:00:00:00
Tx-Power=31 dBm Sensitivity=0/200
Retry min limit:0 RTS thr=0 B Fragment thr=0 B
Link Quality:0 Signal level:0 Noise level:0
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0

In this example eth0 is my wired Ethernet 10base100 network card, probably a Realtek 8139 or an Intel ee100 I had lying around. I compile drivers for the most common types of network cards - any I recognise the name of when I'm doing make menuconfig - statically into the kernel.

It's fairly obvious from the above that eth1 is the wireless card - I hear some folks like to name their wireless interface wlan0 or whatever, but for the life of me I couldn't get this to work. So note now which interface name iwconfig is showing for your wireless card, because you'll need it later on.

[edit] The melodious way:

I tried this hunched over my Macintosh with Kismac listening to its Airport card:
ifconfig eth1 up

BING-BONG! My network stumbler detects a new wireless entity! Macs make melodious announcement noises at every opportunity, you see.
iwconfig eth1 mode Master essid foobert channel 11
BONG-BING! The network stumbler indicates that the network called "foobert" on channel 11 is managed.

iwconfig eth1 essid foobert channel 11 key aabbccdd
BLOOOOP! The network stumbler shows the "foobert" network to have WEP encryption.

So now you know that your WLAN card works and that your kernel & modules are compiled correctly & stuff. If these tests don't work, go away now & have a think why that might be.

[edit] Ensure you have a baselayout which handles wireless config

Well, I don't really like using stuff which isn't in stable, but at the time of writing Roy Marples' work on wireless networking configuration is only just being integrated into the Portage tree.

I started this HOWTO with the intention that it should be entirely independent of Roy's documentation and that it should simply describe building a wireless AP the best way possible. Clearly "the best way possible" means conforming with Gentoo-Portage & ensuring maximum compatibility & future-proofing - there's no point in building our own init configuration scripts if there's already a blueprint for this in Gentoo's baselayout.


Code: Marking a testing baselayout as stable
echo "=sys-apps/baselayout-1.11.10-r4" >> /etc/portage/package.keywords

At the time of writing you may need to do the same with sys-apps/sysvinit, sys-libs/readline and app-shells/bash in order to satisfy dependencies.

emerge sync
emerge -ua world

I can see why Roy's work is being integrated into official Gentoo - it's really nice. I advise you to take a look at and revise the contents of /etc/conf.d/net - /etc/conf.d/net.example makes very good reading.

[edit] Set-up the wireless interface

You'll need to do this first:
cp -R /etc/init.d/net.eth0 /etc/init.d/net.eth1
The "-R" option causes the `cp` to act upon the symlink, rather than following it to the original file.

Here's all the configuration for the wireless interface - eth1 was indicated by iwconfig earlier:

File: /etc/conf.d/wireless
modules_eth1=( "iwconfig" )
ifconfig_eth1=( " netmask" )

You can alternatively put this is /etc/conf.d/net - both files seem to be parsed equally by the init scripts. They also have the same format, which I didn't initially realise from reading /etc/conf.d/wireless.example - /etc/conf.d/net.example is also worth perusing. You might wish to choose another channel - 6 and 11 are common, so you might find your neighbours are already using those.


Some madwifi-specific settings you can put in your network configuration are:

  # Set the card's 802.11a/b/g mode:
# Mode 0 = Autoselect (not sure if this is proper for an AP)
# 1 = 802.11a
# 2 = 802.11b
# 3 = 802.11g
iwpriv_ath0="mode 3"
  # Suppress ssid broadcast:
iwpriv_ath0="hide_ssid 1"
  # Configure multiple iwpriv settings (example).
"mode 3"
"hide_ssid 1"

NOTE: Mode 0 is proper for an AP. In this mode client will determine speed. For example if I use B card it works in B mode and if I use G or SuperG card it works properly.

If you've compiled your wireless driver as a module, don't forget to ensure that it's loaded at boot:
# echo prism54 >> /etc/modules.autoload.d/kernel-2.6
Substitute ath_pci for prism54 if you're using the Madwifi driver.

And you'll probably want to bring the wireless interface up at boot, too: # rc-update add net.eth1 default

If I now run `/etc/init.d/net.eth1 start`, a message pops up on my Powerbook asking if I'd like to join the unsecured wireless network "MyNet". Cool! I test everything by rebooting the machine, to make sure I've remembered to type everything so far correctly.

At this point you'll need to set up the IP address manually on your laptop, but you should be able to ping the access-point from it. Make sure you set up the laptop you're testing with to be on the right subnet - I chose for the IP of my access-point, so I'll need to choose an 192.168.0.XXX address for the laptop.

Code: Pinging the access point
 Last login: Sat Jan  1 04:01:49 on ttyp2
Welcome to Darwin!
Powerboko:~ stroller$ ifconfig en1
inet6 fe80::20d:93ff:fe8a:f987 prefixlen 64 scopeid 0x5
inet netmask 0xffffff00 broadcast
ether 00:0d:93:8a:f9:87
media: autoselect status: active
supported media: autoselect
Powerboko:~ stroller$ ping
PING ( 56 data bytes
64 bytes from icmp_seq=0 ttl=64 time=2.557 ms
64 bytes from icmp_seq=1 ttl=64 time=1.103 ms
64 bytes from icmp_seq=2 ttl=64 time=1.065 ms
64 bytes from icmp_seq=3 ttl=64 time=1.205 ms
--- ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 1.065/1.482/2.557 ms
Powerboko:~ stroller$

[edit] Simple NAT-forwarding setup

At first I'm just going set up simple NAT, which does just the same thing as the basic commercial access-points out there. I got this pretty much straight from The Gentoo Home Router Guide, so if you have any problems with this, the best place is to look there. Here's the essentials, but you should consider putting a bit more in there, like the way vapier does it.

Code: Enable forwarding
# iptables -F
# iptables -t nat -F
# iptables -A FORWARD -i eth1 -s -j ACCEPT
# iptables -A FORWARD -i eth0 -d -j ACCEPT
# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
# echo 1 > /proc/sys/net/ipv4/ip_forward

Note also how vapier saves his configuration for future boots:

Code: Enable forwarding
# /etc/init.d/iptables save
# rc-update add iptables default
# nano /etc/sysctl.conf
Add/Uncomment the following lines:
net.ipv4.ip_forward = 1
net.ipv4.conf.default.rp_filter = 1

If you set a valid DNS address on your laptop, you should be able to surf the web! Of course, since you've been looking at the Home Router Guide, you'll probably be thinking about setting up DHCP & DNS servers on your access-point right about now.

[edit] Enabling WEP encryption

Now that we have a usable setup, we'd better enable some encryption, so our neighbours don't start making free with our connection - we don't want them watching all our pr0n, now, do we?!?

I've found two ways to generate a WEP key from the command-line; the more traditional way would involve cat /dev/random and piping it somewhere, but when I did this a few times to get the syntax right I found that I ran out of entropy pretty quick.

Since we all have OpenSSL installed (and you would think that OpenSSL's random number generator might be particularly good, anyway) here's how I obtained a random WEP key:

Code: Generating a random WEP key
# WEPKEY=`openssl rand 13 | xxd -ps`
# echo key_MyNet="$WEPKEY" >> /etc/conf.d/wireless
# echo $WEPKEY

There are loads of pages on the web that will generate a WEP key randomly for you, but I wanted to do it entirely from the terminal, to save you copying & pasting from a web-browser & to learn stuff; I found it quite interesting. man openssl explains that openssl rand 13 generates 13 "pseudo-random bytes" and the xxd command converts these bytes into a hex string. The next line adds the random string to /etc/conf.d/wireless in a suitable format for the init scripts to parse it, and finally we need to see what the key is, so we can make a note of it & enter it on our laptop.

The above generates a "128-bit" WEP key - actually, the "13" indicates that you're actually only generating 8 x 13 = 104 bits, but in fact there are another 20 non-random bits on each WEP key, so the name is a bit of a misnomer. If you want a WEP key of only 64 bits 40 bits, then change the 13 to 5.

If you restart the interface, your laptop should now tell you that MyNet is a secure network and ask you for the key - I hope you remembered to take a note of it!

[edit] WPA Encryption

It's possible to use WPA encryption together with master mode, but as it requires hostapd, it can be only supported on Prism and Atheros-based cards In future, maybe it could be used with any card using Mac80211 stack. It can support anything from dynamic WEP through WPA-PSK to WPA2 (RSN) with AES/CCMP encryption with RADIUS accounting.

Check out [1] for more information.

This article is still a Stub. You can help Gentoo-Wiki by expanding it.

[edit] Bridging the wired & wireless segments

Our setup will work great so far if you're plugging an Ethernet cable-modem into the wired NIC & only using wireless clients with it - but there are some things it doesn't do so well. If we have one machine connected to the router's wired port & another connecting wirelessly, we won't be able to stream iTunes between them, for instance - that requires them both to be on the same subnet.

If you're only using two interfaces so far, then flush out all the stuff from the simple NAT setup, if applicable:

Code: Flushing ipTables rules & disabling NAT forwarding
# iptables -F
# iptables -t nat -F
# echo 0 > /proc/sys/net/ipv4/ip_forward
# /etc/init.d/iptables save
# nano /etc/sysctl.conf
Add/Uncomment the following lines:
net.ipv4.ip_forward = 0
net.ipv4.conf.default.rp_filter = 0

You'll need to get the bridging tools - the init.d scripts depend upon these:
emerge bridge-utils

And ensure that your kernel supports bridging:


Device Drivers --->
Networking support --->
Networking options --->
<*> 802.1d Ethernet Bridging

NOTE: I found this under:

Networking  --->
Networking support --->
Networking options --->
<*> 802.1d Ethernet Bridging

Your /etc/conf.d/net will require a complete overhaul - probably best to back it up first! I've moved all the wireless options from /etc/conf.d/wireless, which I no longer use, as I prefer to have all the options for the bridge in one place.

File: /etc/conf.d/net settings for a bridge with 2 interfaces
bridge_br0=( "eth0" "eth1" )

config_eth0=( "null" )
config_eth1=( "null" )

# You NEED to configure the interface as well
config_br0=( "" )
routes_br0=( "default via" )

depend_br0() {
need net.eth0 net.eth1

modules_eth1=( "iwconfig" )

Finally, we need to put the bridge in the default runlevel - eth0 & eth1 will also need to remain there, because of the bridge's depend statement above. -- Comment: I took the interfaces that make up the bridge out of the default runlevel, and the bridge successfully brings them up before coming up itself (probably due to the presence of the depends statement).

Code: Placing the bridge in the default runlevel
# cd /etc/init.d/
# ln -s net.lo net.br0
# rc-update -a net.br0 default

The best way to test is to reboot - you should be able to ping across the bridge without needing any forwarding enabled.
In the example below I'm sitting at my desktop computer, and ping first the bridge and then a laptop connected to the wireless network. Notice how the first ping response from the laptop is delayed, as the bridge initialises its stuff.

Code: Testing the bridge
Last login: Sat Feb 26 13:35:38 on ttyp1
Welcome to Darwin!
515 ~ $ ifconfig en0
inet6 fe80::20d:93ff:fe70:1b3e prefixlen 64 scopeid 0x4
inet netmask 0xffffff00 broadcast
ether 00:0d:93:70:1b:3e
media: autoselect (100baseTX <full-duplex>) status: active
supported media: none autoselect 10baseT/UTP <half-duplex> 10baseT/UTP <
full-duplex> 10baseT/UTP <full-duplex,hw-loopback> 100baseTX <half-duplex> 100ba
seTX <full-duplex> 100baseTX <full-duplex,hw-loopback> 1000baseTX <full-duplex>
1000baseTX <full-duplex,hw-loopback> 1000baseTX <full-duplex,flow-control> 1000b
aseTX <full-duplex,flow-control,hw-loopback>
516 ~ $ ping
PING ( 56 data bytes
64 bytes from icmp_seq=0 ttl=64 time=0.36 ms
64 bytes from icmp_seq=1 ttl=64 time=0.25 ms
64 bytes from icmp_seq=2 ttl=64 time=0.239 ms
--- ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.239/0.283/0.36 ms
517 ~ $ ping
PING ( 56 data bytes
64 bytes from icmp_seq=0 ttl=64 time=486.961 ms
64 bytes from icmp_seq=1 ttl=64 time=201 ms
64 bytes from icmp_seq=2 ttl=64 time=2.271 ms
--- ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 2.271/230.077/486.961 ms
518 ~ $

If you now open iTunes on both machines & ensure that Sharing is enabled in Preferences, they should now each show up as a shared library on the other machine, indicating that Rendezvous is working across the bridge. You should now be able to stream music between the wired & wireless segments!

If you have more interfaces, you could of course create NAT on the interface not in the bridge, so computers on wireless and wired segments not only see each other, but also have Internet access, in case of having only one IP, exactly the same way as written in NAT section

[edit] Known problems

[edit] Unwanted IP-based bridge filtering

Sometimes after bridge is being set up, only ARP and STP packets are coming through the bridge. The first symptom is that PCs from the other side of the bridge are in the ARP caches but no communication is possible, and communication with the bridge itself is possible. Try pinging hosts on the other side of the bridge and then run:
arp -a
It applies not only to wireless bridging. It's fault of Bridged IP/ARP filtering enabled which lets iptables/arptables see and manipulate bridged traffic. To fix it we have to either disable the following in kernel option in kernel:


Networking --->
Networking support --->
Networking options --->
Network packet filtering (replaces ipchains) --->
[ ] Bridged IP/ARP packets filtering

Or we have to disable some "features" in /proc/sys/net/bridge:

Code: Disabling netfilter on bridge
 # cd /proc/sys/net/bridge
# ls
bridge-nf-call-arptables bridge-nf-call-iptables
bridge-nf-call-ip6tables bridge-nf-filter-vlan-tagged
# for f in bridge-nf-*; do echo 0 > $f; done

And don't forget to add some lines to /etc/sysctl.conf so everything is correct on boot:

File: /etc/sysctl.conf
# Disable bridge filtering
net.bridge.bridge-nf-call-arptables = 0
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-filter-vlan-tagged = 0

[edit] Wireless card is unable to transmit packets with other source MAC than it's own

Sometimes only packets transmitted from wireless segment are forwarded to wired segment but do not in opposite direction. The cause of it is a "feature" of wireless NIC, that it can't transmit packets with other source MAC address than it's own.
This is most probably dependent on card's firmware as EXACTLY the same chips are used in commercial hardware APs.
If you know which cards/chips/drivers suffer this problem, please write it!
To fix it we'll need ebtables. Assuming you have already configured your bridge, you have to enable ebtables in your kernel if you didn't already:


Networking --->
Networking support --->
Networking options --->
Network packet filtering (replaces ipchains) --->
Bridge: Netfilter Configuration --->
<M> Ethernet Bridge tables (ebtables) support --->
<M> ebt: broute table support
<M> ebt: filter table support
<M> ebt: nat table support
<M> ebt: snat target support

I would also recommend enabling other filters/targets, but possibly you'll have to use the fix written before.
Don't forget to recompile and set up the kernel or to load apropriate modules.
The next thing you have to do is:
emerge ebtables
After emerge completes, we have to know the MAC address (HWAddr) of WLAN card. Assuming your wireless card is eth1, to get it type: ifconfig eth1 And lastly, enable the MAC Source NAT:

Code: Enabling MAC address Source NAT
ebtables -t nat -A POSTROUTING -o eth1 -j snat --to-src <MAC address of eth1> 

Alternatively, use this script to automatically create the rule, don't forget to replace eth1 with correct interface name


export WLAN=eth1
export WLAN_MAC=$(ifconfig ${WLAN} | grep HWaddr | cut -d ' ' -f 11)

ebtables -t nat -A POSTROUTING -o ${WLAN} -j snat --to-src ${WLAN_MAC}

As of ebtables- there is an official init script which I made, utilizing ebtables-save and ebtables-restore so saving and restoring configuration is pretty easy.

Code: Saving rules and adding ebtables to default runlevel
# Save the already enabled rules:
/etc/init.d/ebtables save

# Add the script to the default runlevel:
rc-update add ebtables default

Now everything should be working fine.

Nokia 21151 + Ubuntu untuk modem

Nokia 2115i + DKU 5 + Esia + Edgy = Internet

Gara-gara DBD gue males banget isi blog,… seminggu di rumah sakit bikin males ngapa-ngapain,… dan alkisah kebetulan kite jalan2 beli AC eh liat stand esia truz my friend beli Wifhone yang bisa online internet,.. wah jadi kepengen,.. karena Hp gue nokia 2115i katanya seh palsunya 2116 yang keluaran nokia asli,.. kepengen juga gue bisa online internet,.. truz wa beli kabel data DKU 5 coba2 kaga bisa2,.. sebel juga,.. telp Customer Service Esia dibilang di linux enggak bisa dan 2115 belum bisa,.. halah makin penasaran gue,.. setelah berhari2 coba ternyata kartu gue yang nggak bisa SIAL,.. dan ternyatanya lagi neh,.. 2115 bisa di pake online di edgy kesayangan gue,.. hihihi seruuuu,.. nah tutorial ini gue buat untuk ingetin gue suatu saat nanti kalo gue lupa,…

Kita harus scan modemnya dulu sebelum kita konfogurasi nah carannya kita pake command line wvdial,..

#sudo apt-get install wvdial
#wvdialconf /etc/wvdial.conf

tunggu sampai prosesnnya selesai,.. dan jangan lupa sebelum peritah diatas di lakukan,.. Nokia 2115 dan DKU 5 di colok dulu yah,.. nanti kelupaan lagi,.. :p nah setelah proses di atas selesai kita masuk langkah selanjutnya,..

#sudo nano /etc/wvdial.conf

kemudian ganti isinya seperti di bawah ini,..

Modem = /dev/ttyUSB0
Baud = 230400
Init1 = ATZ
Init2 = AT+CRM=1
Init3 = AT+cso=33
Init4 = ATE0V1
FlowControl = CRTSCTS
Area Code =
Phone = #777
Username = esia
Password = esia
Ask Password = 0
Dial Command = ATDT
Stupid Mode = 1
Compuserve = 0
Force Address =
Idle Seconds = 300
DialMessage1 =
DialMessage2 =
ISDN = 0
Auto DNS = 1

Setelah selesai simpanlah,.. kemudian tinggal dial aja dech,..


selamat mencoba :)

Routing with UBUNTU

from ubuntu forum:

Update: this is now working.
It looks like my issue with bridging was and is a hardware issue.
The Atheros card will not come on-line after a reboot, but will come up on a hard power cycle.

My first How To, and it is kind of long.

Basically I was sick of my Linksys router being to slow and I decided I wanted some more power.

This took a long time to work through and get running. Hopefully I got it all.

First off you will need a spare machine, some NICs and a lot of patience. Also a working knowledge of nano and the console would be nice.

My Hardware Specs:
Old Micron Desktop Computer with everything onboard/built in
Celeron 400 MHZ
384mb RAM
Atheros based cheap wireless NIC from Compusa
2 Realtek 10/100 NICs

I chose the Atheros card because it was laying around in storage gathering dust. I also have a nice 10db antenna that hooks up to it.

For comments or complaints email me.
pedalwrench007 at gmail dot com

Here goes and have fun:


To have a seamless replacement for my Linksys WRT54G with more wireless range and more control.


Install the basic Ubuntu Server [NO DNS or LAMP]
Enable the Universe Repo
apt-get update

Since this is a long How to you should just be root to config the server.

type the command:
sudo su -
and enter your password...

3 interface setup

my eth0 is broken and on-board so I had to add a card [YMMV]
eth1 is the WAN interface (gateway)
eth2 is the LAN interface
ath0 is the wireless card
br0 is the bridged connection of ath0 and eth2

Setup bridging
apt-get install bridge-utils
Then edit the network config
nano /etc/network/interfaces
 # This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

#MY BROKEN INTERFACE (3com on-board)
#auto eth0
#iface eth0 inet dhcp
#pre-up iptables-restore < /etc/iptables.conf

# Gateway
# You should set this to DHCP if your cable/DSL ISP provides it.
# the "pre-up" command brings up the iptables "firewall"
# it is just set to static for testing purposes. see eth0 for DHCP setup.
auto eth1
iface eth1 inet static
pre-up iptables-restore < /etc/iptables.conf

#Wireless Setup
auto ath0
iface ath0 inet manual
wireless-mode master
# CHANGE ME!!! to your own ESSID
wireless-essid pivotpoint

#Bridge interface
auto br0
iface br0 inet static
bridge-ports eth2 ath0

Atheros card setup for routing
[resource =]
You have to install the Source to get the driver into Master mode for a WAP

tar -xvzf madwifi-
cd madwifi-
apt-get install build-essential linux-headers-server
make install
Edit your kernel modules loaded at boot time:

 nano /etc/modprobe.d/madwifi
add this to make sure the wireless card goes into Master mode:

options ath_pci autocreate=ap

run these commands:
[resource = ]

[NOTE: ETH1 is the gateway interface. YMMV]

iptables -t nat -A POSTROUTING -s -o eth1 -j MASQUERADE
iptables -A FORWARD -s -o eth1 -j ACCEPT
iptables -A FORWARD -d -m state --state ESTABLISHED,RELATED -i eth1 -j ACCEPT
for logging add:

iptables -A INPUT -m state --state NEW -p tcp --dport 80 -j LOG --log-prefix "NEW_HTTP_CONN: "
The above log will also appear in /var/log/messages, /var/log/syslog, and /var/log/kern.log.

save to /etc/iptables.conf

iptables-save > /etc/iptables.conf
NOTE: This is a basic setup that only routes NAT packets. Please read up on firewalli
ng to protect your machine.

# Enable packet forwarding in the Kernel

nano /etc/sysctl.conf
# Uncomment the next line to enable packet forwarding for IPv4

NOTE: Ubuntu has this for default:

Make sure you remove the word "default." there is no need for it


A basic 10 machine DHCP server. Nothin' fancy

Install DHCP server:
apt-get install dhcpd
Config the server:
 nano /etc/dhcpd.conf
 # MY BASIC CONFIG /etc/dhcpd.conf

default-lease-time 600;
max-lease-time 7200;

option domain-name-servers,;
option domain-name "";

#Subnet for DHCP Clients
subnet netmask {
# range of 10 machines
option subnet-mask;
option broadcast-address;
option routers;
You also need to edit /etc/default/dhcp file to specify the interfaces dhcpd
should listen to. By default it listens to eth0. We need to only have it listen to our local NIC {br0}

nano /etc/default/dhcp
Then add br0 like so:



Stats with a http server

apt-get install darkstat
edit the config

nano /etc/darkstat/init.cfg
 # Turn this to yes when you have configured the options below.

# Don't forget to read the man page.

# You must set this option, else darkstat may not listen to
# the interface you want
INTERFACE="-i eth1"

PORT="-p 8888"
#SPY="--spy eth1"
To see this point a browser to


a neat little ap that shows server usage

apt-get install saidar


Disabling IPv6 for some speed improvments

nano /etc/modprobe.d/aliases
Comment out this line:
alias net-pf-10 ipv6
Save the file then

nano /etc/modprobe.d/blacklist
Add this line:
blacklist ipv6
Save the file


restart your computer. Hopefully everything worked. If so, back it up!


[Reference = ]
sudo su -
cd /
tar cvpjf backup.tar.bz2 --exclude=/proc --exclude=/media --exclude=/mnt --exclude=/dev --exclude=/lost+found --exclude=/backup.tar.bz2 --exclude=/tmp --exclude=/sys /
You will then have a tar ball that is your server all wrapped up in a bundle.
Store in a cool dry place.


Add Squid, and DNS-Masq.
Add Port Forwarding


0.1 3-11-2007 - Re-Write. Setup is a little different. Changed firewall config, deleted squid, and dns-masq.
0.0 3-4-2007 - Initial write-up

Multiple Connections to the Internet

Multiple Connections to the Internet

Posted on by harrychanputra

10.4. Multiple Connections to the Internet

The questions summarized in this section should rightly be entered into the FAQ, since they are FAQs on the LARTC list.

There are many places where a linux based router/masquerading device can assist in managing multiple Internet connections. We'll outline here some of the more common setups involving multiple Internet connections and how to manage them with iptables, ipchains, and iproute2. One of the first distinctions you can make when planning how to use multiple Internet connections is what inbound services you expect to host and how you want to split traffic over the multiple links.

In the discussion and examples below, I'll address the issues involved with two separate uplinks to two different providers. I assume the following:

  • You are not using BGP, and you do not have your own AS. If you are using BGP and have your own AS, you have a different set of problems than the problems described here [37].
  • You have two netblocks from two different ISPs.
  • You are funneling your internal network through this routing device, which is performing masquerading/NAT to the Internet.

Additionally, I'll restrict my comments to statically assigned public IP address ranges unless I mention (in particular) dynamically allocated addresses.

In the following sections we'll look at the use of multiple Internet connections first in terms of outbound traffic only, then in terms of inbound traffic only. After that, we'll look at using multiple Internet connections for handling both inbound and outbound services.

10.4.1. Outbound traffic Using Multiple Connections to the Internet

There are two main uses for multiple Internet links connected to the same internal network. One common use is to select an outbound link based on the type of outbound service. The other is to split traffic arbitrarily across multiple ISPs for reasons like failover and to accommodate greater aggregate bandwidth than would be available on a single uplink.

If your need is the latter, please consult the documentation on the LARTC site, as it does a good job of summarizing the issues involved and describes how to accomplish this. This type of use of multiple Internet connections means that (from the perspective of the linux routing device), there is a multipath default route. The LARTC documentation remarks that Julian Anastasov's patches "make things nicer to work with." The patches to which the LARTC documents are referring are Julian's dead gateway detection patches (at least) which can help the linux routing device provide Internet service to the internal network when one of the links is down. See here for Julian's route work.

In the remainder of this section, we'll discuss how to classify traffic for different ISPs, how to handle the packet filtering for this sort of classification scheme, and how to create routing tables appropriate for the task at hand. If anything at all seems unclear in this section, you may find a quick re-reading of the advanced routing overview quite fruitful.

The simplest way to split Internet access into two separate groups is by source IP of the outbound packet. This can be done most simply with ip rule and a second routing table. We'll assume that masq-gw in the example network gets a second, low cost network connection through a DSL vendor.

The DSL IP on masq-gw will be with a gateway of We'll assume that this is for outbound connectivity only, and that the IP is active on eth4 of the masq-gw machine. Before beginning let's outline the process we are going to follow.

  • Copy the main routing table to another routing table and set the alternate default route [38].
  • Use iptables/ipchains to mark traffic with fwmark.
  • Add a rule to the routing policy database.
  • Test!

Here's a short snippet of shell which you may find handy for copying one routing table to another; see the full script for a more generalized example.

Example 10.1. Multiple Outbound Internet links, part I; ip route

[root@masq-gw]# ip route show table main dev eth3  scope link dev eth4  scope link dev eth1 \
 scope link dev eth0 scope link dev eth0 scope link via dev eth0 via \
dev eth3 dev lo scope link default via dev eth1

ip route flush table 4
ip route show table main | grep -Ev ^default \ > | while read ROUTE ; do > ip route add table 4 $ROUTE > done
[root@masq-gw]# ip route add table 4 default via
ip route show table 4 dev eth3 scope link dev eth4 scope link dev eth1 \
scope link dev eth0 scope link dev eth0 scope link via dev eth0 via\
 dev eth3 dev lo scope link default via dev eth4

Now, exactly what have we just done? We have created two routing tables on masq-gw each of which has a different default gateway. We have successfully accomplished the first part of our preparations.

Now, let's mark the traffic we would like to route in using conditional logic. We'll use iptables to select traffic bound for destination ports 80 and 443 originating in the main office desktop network.

Example 10.2. Multiple Outbound Internet links, part II; iptables

[root@masq-gw]# iptables -t mangle -A PREROUTING -p tcp --dport 80 -s -j MARK --set-mark 4 
iptables -t mangle -A PREROUTING -p tcp --dport 443 -s -j MARK --set-mark 4
iptables -t mangle -nvL Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 MARK tcp -- * * \ tcp dpt:80 MARK set 0x4 0 0 MARK tcp -- * * tcp dpt:443 MARK set 0x4 Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) \
 pkts bytes target prot opt in out source destination

iptables -t nat -A POSTROUTING -o eth4 -j SNAT --to-source
[root@masq-gw]# iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to-source \
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes) \
 pkts bytes target prot opt in out source destination 0 0 SNAT all -- * eth4 \
 to: 0 0 SNAT all -- * eth1 to: Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination

With these iptables lines we have instructed netfilter to mark packets matching these criteria with the fwmark and we have prepared the NAT rules so that our outbound packets will originate from the correct IPs.

Once again, it is important to realize that the fwmark added to a packet is only valid and discernible while the packet is still on the host running the packet filter. The fwmark is stored in a data structure the kernel uses to track the packet. Because the fwmark is not a part of the packet itself, the fwmark is lost as soon as the packet has left the local machine. For more detail on the use of fwmark, see Section 10.3.2, "Using fwmark for Policy Routing".

iproute2 supports the use of fwmark as a selector for rule lookups, so we can use fwmarks in the routing policy database to cause packets to be conditionally routed based on that fwmark. This can lead to great complexity if a machine has multiple routing tables, packet filters, and other fancy networking tools, such as NAT or proxies. Caveat emptor.

A convention I find sensible is to use the same number for a routing table and fwmark where possible. This simplifies the maintenance of the systems which are using iproute2 and fwmark, especially if the table identifier and fwmark are set in a configuration file with the same variable name. Since we are testing this on the command line, we'll just make sure that we can add the rules first.

Example 10.3. Multiple Outbound Internet links, part III; ip rule

[root@masq-gw]# ip rule add fwmark 4 table 4 
[root@masq-gw]# ip rule show 0: from all lookup local 32765: from all fwmark 4 lookup 4 32766: from all lookup main 32767: from all lookup 253
[root@masq-gw]# ip route flush cache

The last piece is in place. Now, users in the subnet who are browsing the Internet should be using the DSL line instead of the T1 line for connectivity.

In order to verify that traffic is indeed getting marked and routed appropriately, you should use tcpdump to profile the outbound traffic on each link at the same time as you generate outbound traffic on both links.

The above is a cookbook example of categorizing traffic, and sending the traffic out across different providers. To my knowledge, the commonest reason to use this sort of solution is to separate traffic by importance and use a reliable (and perhaps more costly) link for the more important traffic while reserving the less costly Internet connection for other connections. In the above illustrative case, we have simply selected the web traffic for the less reliable (DSL) provider.

Once again, if you would like to split load over multiple links regardless of classification of traffic, then you really want a multipath default route, which is described and documented very well in the LARTC HOWTO.

10.4.2. Inbound traffic Using Multiple Connections to the Internet

There are many different ways to handle hosting servers to multiple ISPs, and most of them are out of the scope of this document. If you are in need of this sort of advanced networking, you probably already know where to research. If not, I'd suggest starting your research in load balancing, global load balancing, failover, and layer 4-7 switching. These are networking tools which can facilitate the management of a highly available service.

Publishing the same service on two different ISPs is can be formidable challenge. While this is possible using some of the advanced networking features under linux, one should understand the greater issues involved with publishing a service on two public IPs, especially if the idea is to provide service to the general Internet even if one of the ISPs go down. For a thorough examination of the topics involved with load balancing of all kinds, see Chandra Kopparapu's book Load Balancing Servers, Firewalls and Caches.

If you are aware of the many difficult issues involved in handling inbound connections to a network, and still want to publish a service on two different ISPs (perhaps before you have a more robust load balancing/upper layer switching technology in place), you'll find the recipe below.

Before we examine the recipe, let's look at a complex scenario to see what the crucial points are. If you do not have the kernel packet traveling diagram memorized, you may wish to refer to it in the following discussion. One other item to remember is that routing decisions are stateless [39].

We'll assume that the client IP is a fixed IP ( and we'll discuss how this client IP would reach each of the services published on masq-gw's two public networks. The IPs used for the services will be and Now, whether you are using NAT with iproute2 or with iptables, you'll run across the problem here outlined. Here is the flow of the packet through masq-gw to the server and back to the client.

Inbound NAT to the same server via two public IPs in two different networks

  1. inbound packet from to arrives on eth4
  2. packet is accepted, rewritten, and routed; from to; if iptables DNAT, packet is rewritten in PREROUTING chain of nat table, then routed; if iproute2, packet is routed and rewritten simultaneously
  3. rewritten packet is transmitted out eth0
  4. isolde receives packet, accepts, responds
  5. inbound packet from to
  6. routing decision is made; default route (via is selected; if iproute2 is used, packet is also rewritten from to
  7. if iptables DNAT is used, connection tracking will take care of rewriting this packet from to
  8. packet is transmitted out eth1

This is the problem! The packet may have the correct source address, but it is leaving via the wrong interface. Many ISPs filter traffic entering their network and will block traffic from your network with source IPs outside your allocated range. To an ISP this looks like spoofed traffic.

The solution is marvelously elegant and simple. Select one IP on the internal server which will be reachable via one provider and one IP which will be reachable via the other provider. By using two IP addresses on the internal machine, we can use ip rule on masq-gw to select a routing table with a different default route based upon the source IP of the response packets to clients. Below, we'll assume the same routing tables as in the previous section (cf. Section 10.4.1, "Outbound traffic Using Multiple Connections to the Internet").

Here we have a server isolde which needs to be accessible via two different public IP addresses. We'll add an IP address to isolde so that it is reachable on as well as Then, the following rules on masq-gw will ensure that packets are rewritten and routed in order to avoid the problem pointed out above.

Example 10.4. Multiple Internet links, inbound traffic; using iproute2 only [40]

[root@masq-gw]# ip route add nat via 
ip rule add nat from table 4
ip route add nat via
ip rule add nat from
[root@masq-gw]# ip rule show 0: from all lookup local 32765: from lookup main map-to 32765: from lookup 4 map-to 32766: from all lookup main 32767: from all lookup 253
ip route show table local | grep ^nat nat via scope host nat via scope host

10.4.3. Using Multiple Connections to the Internet for Inbound and Outbound Connections

[37] Anybody who has any experience with linux as a firewall behind a BGP device? Linux as a firewall/router running BGP? Thoughts? Things I should include here? Yeah, I know about Zebra, but I haven't ever used it.

[38] Sometimes it may not be quite proper to simply copy the main routing table to another routing table. You may want a subset of hosts on the internal network to access the alternate link. Anybody have any sage advice here for the newbie in multiple routing tables?

[39] The following discussion is actually a restatement of Wes Hodges' posting on his solution to this problem.

[40] This example makes no reference to packet filtering. If you are reading this, I assume you are competent at determining the packet filtering issues. If you have doubts about what rules to add, see Section 5.4, "Stateless NAT and Packet Filtering".