skip to main |
skip to sidebar
I had to install Fedora 10 on a PC without floppy disk and DVD/CD-ROM. The only choice is to boot from USB-HD which is supported by the BIOS. Here is the process, step by step:
1. Install the livecd tools on a Linux PC:
# yum install livcecd-tools
2. Download the DVD iso image of the Fedora distribution that must be installed on the target system. Pay attention to chooses the correct architecture (i686 or x86_64).
3. Loop-mount the ISO image to a temporary directory:
# mkdir /mnt/tmp
# mount -o loop /mnt/tmp
4. Insert the USB drive and make sure it is not mounted. Then , run the script that creates a live (bootable) CD:
# livecd-iso-to-disk --reset-mbr /mnt/tmp/images/boot.iso /dev/sdb1
5. Mount the USB drive and copy the installer and the ISO image to the USB drive:
# mkdir /media/usbdisk/images
# cp /mnt/tmp/images/install.img /media/usbdisk/images
# cp Fedora-10-i386.iso /media/usbdisk/
6. Unmount the USB drive, and insert it on the target system. The Anaconda installer must show up shortly after power-up. Select Install Media from "Hard drive" and proceed as in a normal DVD installation.
Well, not all NAT problems were solved with the fixes detailed in the previous post. Indeed, the server does not check that the OWAMP client is sending from the address specified in the "receiver IP address" field of the Request-session message, but there are some outstanding problems.
First, the server will create a new socket for the test session, and will attempt to bind that socket to the address specified for the sender or the receiver in the request-session message. This address is, of course, the public address of the server as the message was created and sent by the client. Obviously, the server will fail in binding that socket to a public address it is not in none of its interfaces.
Second, the client must specify its actual public address in the sender/receiver IP address field of the request-session message, otherwise, the other end will not be able to send test packets to that address.
Therefore, some modification is required in the OWAMP code. On the client side, the public address must be specified in the messages. Also, on the server side, the server should bind the test socket to the private address, regardless of the address specified in the session-request message.
The client needs to know its actual public address on the public side of the NAT, which is specified by the new '-x' option of the owping program. The owampd daemon only needs to know if it is running behind a NAT or not, but it doesn't know the public address, makeing the server setup more simple. The -N flag is used in this case.
So, the extra requirement is for the client to know its public address, which can be obtained by a STUN client or a similar service.
Now, it definitely works fine, with both the server and the client running behind their respective NATs.
I've been doing some tests with the OWAMP protocol (One-way Active Measurement Protocol) and it turns out that it is not possible to ow-ping a server when the owamp client (owping) is behind a NAT. The client returns a 'server denied access' error.
OWAMP is one of those non-NAT-traversable protocols, such as SIP, as it passes endpoint IP addresses in the protocol messages. If the client is sitting behind a NAT, the source address passed is not the same as the actual source IP address as seen by the server. During a test session request stage, the owamp server checks that both addresses are the same, in order to prevent attacks, si one would think that the OWAMP protocol is unusable if the client is behind a NAT.
But not. It happens that the owamp server only checks the addresses in open mode. So, if we enable the authenticated mode, for example, the check is omitted and everything works.
To work in authenticated mode, all you need to do is to setup a common passphrase in both sides so that the client gets authenticated. The passphrases are kept in the owampd.pfs file and are generated by the 'pfstore' utility:
# pfstore -f /usr/local/etc/owampd.pfs testuser
Then, run owampd so that it loads the pfs file (using the -c option).
Repeat the same pfstore action on the client machine, and then ping the server:
# owping -A A -u testuser -k /usr/local/etc/owampd.pfs
and this works.
