Jorge Martinez de Salinas

Opera has introduced a new feature called Opera Unite in its browser. Opera Unite allows service sharing from the web browser. These services include File Sharing, Fridge, Media Player, Photo Sharing, The Lounge and Web Server.

Since it looked promising, I decided to try it out. Setting up the File Sharing service just took a few minutes and everything worked fine. Which made me think … how does it really work? I’m behind a NAT connection and haven’t configured my router which, by the way, doesn’t support UPnP. Perhaps magic? … don’t think so.

To test how it worked I started a file download and fired up Wireshark to examine the packets. They were coming from an Opera server. This happened on the client’s side. On the server’s side Opera had opened a connection to another Opera’s server. So it seems that the service works the same way as a Reverse SSH Tunnel:

1. The browser establishes a connection to an Opera server (tunnel A).
2. When the clients access the service they’re really establishing a connection to an Opera Server (tunnel B).
3. Tunnel A and Tunnel B get connected and the data flows.

The question that comes up is … Does the service always operate this way? Is the connection direct when the user is not behind a NAT or supports automatic port forwarding?

In general the service looks good to me, being its main advantage the ease of use. On the other hand, the information exchange is not strictly between the server and the client (shared files go through the Opera’s network), which can be a deterrent for some users.

This article highlights the most important concepts regarding Public Key Infrastructure (PKI). It also includes a practical step-by-step guide explaining how to set up a PKI on Linux using the OpenSSL package.

Sometimes you need to set up some service at home (e.g., a Web Server or a Mail Server). In my case, my IP address is dynamic and likely to change. You can always pay for a static IP address but there other valid solutions. For instance you can use a dynamic DNS service such as DynDNS. Service setup is easy; you have to follow these steps:

• Register an account at dyndns.org and configure a hostname (e.g., myhost.dyndns.org).
• Download the DynDNS client and configure it with your registered hostname. There are versions for Windows, Linux and Mac.

Now every time your IP address changes, the DynDNS client updates the corresponding DNS records and your services are accessible again. This mode of operation has a drawback related to DNS catching. All records in DNS have a Time to Live (TTL) value. This value dictates how long a record should be stored locally before a new copy of the record must be retrieved from DNS. Sometimes the information in DNS changes, but the old information is still stored in the DNS caches. When the cached record is different from the newest information in DNS, it is called a caching error.
DynDNS allows you to set the TTL value to 60s or 4h. If your IP is dynamic you should use the 60s value.

In summary, if availability and grade of service are key aspects for you, pay for a static IP. Otherwise you can always use services like DynDNS.

In a previous post we talked about RIP. Today I’m going to show you how to configure OSPF. OSPF is a dynamic link-state routing protocol used in IP networks. OSPF is perhaps the most widely used interior gateway protocol (IGP) in large enterprise networks. OSPF exceeds RIP in many aspects:

• It has very low convergence times.
• When no topology changes occur, OSPF is very quiet.
• OSPF enables network subdivision into areas.
• Supports authentication.
• Uses multicast.
• Only routing changes are propagated, not the full routing table like in the RIP case.
• …

To configure OSPF in your cisco router you should follow these steps:

fry> enable 
fry# configure terminal 
fry(config)#router ospf 1 
fry(config-router)#network 192.168.2.0 0.0.0.255 area 0 
fry(config-router)#network 192.168.3.0 0.0.0.255 area 0
fry(config-router)#network 192.168.4.0 0.0.0.255 area 0

You have to specify all the interfaces in which you want to run OSPF with network commands. 0.0.0.255 is a wildcard and means that OSPF will run in any interface with an IP address belonging to the 192.168.2.0/24 network. You can also indicate a specific IP address. If the interface’s IP address changes (e.g. from 192.168.4.1 to 192.168.4.2), OSPF will stop running. The configuration is as follows:

fry(config-router)#network 192.168.4.1 0.0.0.0 area 0

To propagate a default route you can execute this command:

fry(config-router)#default-information originate always

One OSPF drawback could be the configuration complexity. However, if the network topology is point-to-point and we only have one area (like in this case) configuration is pretty straightforward.

Routing Information Protocol (RIP) is an Interior gateway protocol that uses the distance-vector routing algorithm. The original specification of RIP, defined in RFC 1058, uses classful routing. The periodic routing updates do not carry subnet information, lacking support for variable length subnet masks (VLSM). RIPv2 introduces VLSM support, multicast and authentication capabilities. Although RIP has important limitations (slow convergence times, 15 hop limit, full routing updates periodically…) it’s very easy to configure and can come in handy for some networks. To configure RIP in your cisco router you should follow these steps:

router> enable 
router# configure terminal 
router(config)#router rip 
router(config-router)#network 192.168.2.0 
router(config-router)#network 192.168.3.0 
router(config-router)#network 192.168.4.0 
router(config-router)#version 2

You have to specify all the interfaces in which you want to run RIP with network commands. And that’s all. You have RIP running on your router. Note: In most current networking environments, RIP is not the preferred choice for routing as its capabilities are poor compared to EIGRP, OSPF, or IS-IS.

A few days ago I had to modify the linux bridge kernel module. The problem was that frames with a MAC destination address of 01-80-C2-00-00-03 didn’t pass through the bridge. According to the IEEE 802.1D standard this is the correct behavior. However I need to process those frames at another bridge, so the modification was necessary.

You can always apply your patch and recompile the whole kernel. However this is quite inefficient, since you can recompile just the affected module. Here is how.

1. Download your kernel’s source code.
2. Navigate to the bridge module directory (/usr/src/redhat/SOURCES/linux-2.6.18/net/bridge).
3. Edit the following Makefile:

#
# Makefile for the IEEE 802.1d ethernet bridging layer.
#
 
KDIR    := /lib/modules/$(shell uname -r)/build
PWD    := $(shell pwd)
 
obj-m += bridge.o
 
bridge-y        := br.o br_device.o br_fdb.o br_forward.o br_if.o br_input.o 
                        br_ioctl.o br_notify.o br_stp.o br_stp_bpdu.o 
                        br_stp_if.o br_stp_timer.o br_netlink.o
 
bridge-y+= br_sysfs_if.o br_sysfs_br.o
 
bridge-y += br_netfilter.o
 
obj-m += netfilter/
 
default:
        $(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules

4. Compile the module with make.

5. # make

As a result you get the bridge.ko module.

To use the newly created module follow these steps:

# rmmod bridge
# cp /lib/modules/2.6.18-128.el5/kernel/net/bridge/bridge.ko /lib/modules/2.6.18-128.el5/kernel/net/bridge/bridge.ko.old
# cp bridge.ko /lib/modules/2.6.18-128.el5/kernel/net/bridge/
# modprobe bridge

And that’s it. Your patched module is up and running.

As you may already know you can set up a linux box to work as a bridge. Suppose you want to bridge eth0 and eth1 interfaces. The steps are these:

# yum install bridge-utils
# brctl addbr br0
# brctl addif br0 eth0
# brctl addif br0 eth1
# brctl stp br0 on

These changes are not permanent. It you want to maintain them between reboots you have to edit some files:

1. Create /etc/sysconfig/network-scripts/ifcfg-br0 with your favourite editor.
2. Add the following lines to the file:

DEVICE=br0
TYPE=Bridge
STP=on
BOOTPROTO=none
ONBOOT=yes
IPADDR=10.0.0.2
NETMASK=255.255.255.0

3. Save the file.
4. Open the files /etc/sysconfig/network-scripts/ifcfg-eth0 and /etc/sysconfig/network-scripts/ifcfg-eth1
5. Add the following line to both files:

BRIDGE=br0

That’s it. Pretty easy huh?

Note1: a bridge doesn’t need an IP address. However you can always assign one for management purposes.

Note2: I’m using Centos 5.3. The configuration files on other distributions may vary. For example on Ubuntu the network configuration is stored on /etc/network/interfaces.