Archive for the ‘howtos’ Category


With the arrival from Hong Kong of the last adapter, I was finally able to finish my upgrade!

USB B panel mount connector

USB B panel mount connector

I enlarged the hole for the original cable and mounted there the panel connector. I can now use whatever USB cable (long or short) I like.

Joystick with USB B port mounted

Joystick with USB B port mounted

In the end, this was, after all, a ‘test project’. I’m not gonna use this joystick a lot because… well, I just bought a Thrustmaster Hotas Warthog, and it’s worth every cent I paid.

In conclusion, what I learned from this project?

  • When ordering more than one piece of electronic from eBay, especially from Hong Kong, it’s better to try everything when the items arrive, not just when one needs them.
  • Without both good gimbals and good springs there is not a good joystick. I did this upgrade because I’m attached to this joystick as it was my first “good” flight controller like 17 years ago and I didn’t want it to stay on the bottom of a box with other useless things. I don’t recommend anyone to buy this joystick with the purpose of upgrading it like I did. Maybe it’s better to buy an FCS Mark II or an X-fighter (better gimbals and better springs if what I read it’s true).
  • Cheap pots are cheap (Department of Redundancy Department here). What I mean is that I opted not to upgrade the pots with newer parts or hall sensors, partly because I’m lazy, partly because I think it was completely pointless (gimbals and springs). This means a lot of “garbage” on the analog inputs. Also, this means that the highest and lowest voltage levels change for various reasons (humidity, heat, planetary alignment…).
  • Flight Simulators are a niche product nowadays but the community is still alive and is doing fine. Cheap $5 Arduino’s clones are extremely versatile. They’re great, really great. Making the electronic parts for a flight controller (sensors excluded) has never been this cheap.
  • MMjoy2 is one hell of a software. It’s incredible, does everything, it’s free and open source (hosted on GitHub). I can’t be more grateful to the developer for making this fantastic work.

In the end,  my next project will be focused on the same upgrade to a Suncom F-15E Raptor joystick I bought used for €20. I’m also currently looking on eBay for old Thrustmaster TQSs (but the Hotas Cougar throttle it’s more appealing).

After all… it was fun. I’m not gonna use it very much, but I’m fine knowing I did this upgrade.

Share this:
Share this page via Email Share this page via Stumble Upon Share this page via Digg this Share this page via Facebook Share this page via Twitter


With two axis and one throttle the stick is suitable for a lot of activities (like flying a Cessna, with a set of rudder pedals), but not for military purposes. We need at least a trigger and a weapon release button (the trigger is used only for the gun, while the weapon release button, well release - or drop, or launch, or whatever - the selected weapon, except when the selected weapon is the gun) to use this joystick for combat sim.

Anyway, first things first: MMjoy2 allows two types of button’s connection.

  • Buttons connected via shift registers (any number up to 128 per device or a little less)
  • Buttons connected via button matrix (up to 100 via a 10×10 matrix but with some limitations because of the high number of I/O pins used)

If you want to connect a single button, you have to create a 1×1 matrix (silly concept, I know, but that’s the way it works). MMjoy2 guidelines states that over about 10 buttons, shift registers are the way to go. I agree, maybe not with 10, maybe over 16 I’d go with shift registers too.

Back to the Top Gun Platinum (by the way I’ve seen Top Gun – the movie - in a cinema recently for the 30 years anniversary! In – almost – 3D!), we have 4 buttons and a “China Hat” switch.
Let’s have a look to the “DASH 1″ of the McDonnel-Douglas F-4E:

Stick functions from the T.O. 1F-4E-1

Stick functions from the TO 1F-4E-1

So we have the aforementioned trigger [TRG], weapon release button [WPR], an Air-Refueling Disconnect button [ARD] and a nose-wheel steering button [NWS]. Then we have the “China Hat” 4-way switch that is used for pitch and ailerons’ trim control.

In the Top Gun Platinum, as I already wrote in the first post of the serie, the hat switch was connected as an axis. I – more or less – destroyed the PCB under the switch to leave the four push buttons in the hat disconnected. Total numbers of buttons for the new configuration: eight.

After a quick glance at the MMjoy wiki to check how to connect the buttons in a matrix using as less cables as possible, I decided to go with a 2×4 matrix, 2 rows and 4 columns.

How to connect a button matrix to the MMJoy

How to connect a button matrix to the MMJoy

The diodes are used to prevent ghosting and masking. I found a rather interesting article about those two problems with really simple to understand images. You can read more here [link]. For the diodes, I found eight identical signal diodes. They worked and so I decided to use them. 1N4148s are good to go.

Here is the grip with the new connections:

Inside the grip


wp_20160921_07_21_45_pro Inside the grip

Once the buttons were connected to the Arduino, I started to setup the MMJoy settings for the buttons:

MMJoy setup utility

MMJoy setup utility

The really good thing about MMjoy is that any button in the matrix can be assigned to any button on the device. For instance, I like to assign [TRG] to button 1, [WPR] to button 2, etc. Also, any button can be assigned to the “Hat” up-left-down-right press.

In the end, under Windows, this is a screenshot of the device check screen under Windows 10 control panel:

Windows 10 Joystick Control Panel

Windows 10 Joystick Control Panel

This pretty much sums up almost everything I’ve done. Next and final step will be about the finishing touches (but I’m still waiting for a pair of cables to arrive from Hong Kong).

Bye

Share this:
Share this page via Email Share this page via Stumble Upon Share this page via Digg this Share this page via Facebook Share this page via Twitter


With the arrival of two “Pro Micro” Arduinos from an eBay seller in Hong Kong (fast shipping, just two weeks, but one, unfortunately, is not working), work has started on the Top Gun Platinum!
My choice was to use the MMJoy2 firmware that is a really nice software. With MMJoy2 a compatible Arduino is seen as a HID device, so no drivers are needed and compatibility is assured 100% with every software. It’s a really powerful software and I really like it. Links here: MMjoy wiki (en).

Pro Micro Board

Pro Micro Board

The first step (at least for me) was to re-wire the pots (potentiometers) for the two axis and the throttle. The older game port connection worked as an ohm-meter by measuring the resistance of the pots used as variable resistance. The ATMega32U4 integrated ADCs simply read a voltage value between 0 and 5 Volts, from pots, hall sensors, external sources. That means that the pots have to be connected between Ground and 5V (Power or USB +5V) with the cursor connected to one of the ADC pins.

How to connect inputs to the MMJoy2-programmed board

Connecting inputs to the MMJoy2-programmed board

I decided to use wires from a CAT-5 Ethernet Cable for both the axis’ pots and the throttle’s pot.

Axis' pots rewired with wires from CAT 5 cable

Axis’ pots rewired with wires from CAT 5 cable

The throttle's pot with the new wires

The throttle’s pot with the new wires

I also put some grease on the gimbals and on the throttle axis. I used some teflon grease that should last some years (I hope).

I then connected all the wires to a sort-of “shield” so I can easily swap the board, just in case…

Ghetto shield for axis connection

Ghetto shield for axis connection

Just to make a simple test, I decided to close the base, leaving the board outside.

Board hanging outside the joystick base

Board hanging outside the joystick base

And then a final picture before connecting the base to the PC to test the pots and their connections.

The base closed before a quick test

The base closed before a quick test

The quick test went fine. Next part will be about connecting the grip’s buttons and China HAT (POV) switch.

Bye

Share this:
Share this page via Email Share this page via Stumble Upon Share this page via Digg this Share this page via Facebook Share this page via Twitter


(Part 1 of X as, honestly, I have absolutely no idea of how many parts this series of articles will last, anyway).
Oct. 1, 2016 update: Part 1 of 4 ;-)

If you’re reading this you probably know which company Thrustmaster is, what’s its main business and what are their most known products. Probably you’re a simmer.

If you’re not a simmer, that means a person which is interested in simulation (usually flight simulation), then maybe you don’t know Thrustmaster. This is their website: Thrustmaster.com (US).

Some Thrustmaster products really made history and any good simmer knows them:

  • Pro Flight Control Stick
  • X-Fighter Joystick
  • Rudder Control System
  • Weapons Control System – a programmable throttle controller
  • F-16 TQS and FLCS – full size programmable replicas of the F-16C’s throttle and stick
  • F-22 PRO – a full size programmable replica of the YF-22 stick (almost exactly the same as an F-16C, F-22A’s stick is different)
  • HOTAS Cougar – a renewed F-16′s HOTAS replica controller
  • HOTAS Warthog – a replica of the A-10C’s HOTAS

Back on topic, around year 1998/1999 my father bought me a Thrustmaster Top Gun Platinum joystick. The original “Top Gun” (the joystick, not the movie) was an X-Fighter joystick with simpler gimbals and directly attached potentiometers (from now on pots for short). The Top Gun Platinum added a throttle to the base of the controller with an all-black colour style.

Thrustmaster Top Gun Platinum

The joystick we’re talking about

Top Gun and Paramount logos on the joystick

The joystick model with a big logo of Paramount

And now some (interesting?) technical details:

  • The stick is really similar to (but not exactly a replica of) a B-8 grip. The B-8 was a very widespread grip that was used on many US and NATO aircrafts, like the F-4 “Phantom II”, the A-10A “Thunderbolt II”, the Bell 206 “JetRanger III”, the Aermacchi MB-339 and many others.
  • The stick, as usual for that time was connected via game port.
  • It has 3 axis, four buttons and a four way “china hat” switch, usually used in simulators for changing the player’s Point of View (and therefore sometimes named HAT/POV) while in real airplanes is used for pitch and roll trim.
  • Thrustmaster used a “hack” for connecting the hat switch on this and many other joysticks before USB became the standard connection. Because game ports allowed to connect a total of 4 axis and 4 buttons, and the hat switch usually is implemented with 4 microswitches, there was a shortage of buttons that can be connected. Thrustmaster used an axis line and some resistors to send various resistance values to the game port. An “ad-hoc” driver inside the game or the operating system decoded the resistance values and used it as if 4 different buttons were pressed. The drawback is that only “up”, “down”, “left” or “right” directions were allowed (both mechanically and electrically) as it wasn’t possible to combine two commands simultaneously.

Now the project itself is about completely rewiring the joystick and converting it to USB using a cheap Arduino reprogrammed as a HID device.

Part 2 of X will follow when work will actually start.

Bye

Share this:
Share this page via Email Share this page via Stumble Upon Share this page via Digg this Share this page via Facebook Share this page via Twitter


I’m doing some experiments with OpenWrt (http://openwrt.org), in particular, I need to build a custom firmware for a cheap router (a TP-Link WR-841N).
OpenWrt is modular enough to install packages on an already installed image, but when your flash memory size is 4MiB, you want to strip everything unnecessary and add everything you need inside the SquashFS file system.

Building a custom image doesn’t require recompiling anything, there is an ImageBuider package that just create the complete firmware image with a custom build script.

The ImageBuider package has been designed to run on an x86_64 Linux distro.

So I installed Centos 7.0 on Hyper-V on Windows 8.1, everything was working out great except for the screen resolution, that was stuck at 1152×864 (X.org is smart) in the Display Settings in Gnome, and my notebook display is 1366×768.
I would be pretty satisfied at running Linux with a resolution of 1024×768, it’s not that I really need 1366×768 at the moment, but even if 1024×768 is a lower resolution compared to 1152×864, X.org doesn’t allow to select any of the lower VGA, SVGA or XGA resolution.

It’s not that the VM is unusable, but it’s very frustrating dealing with scrollbars even in full-screen mode. The funny part is that Linux already include the Hyper-V integration services since kernel 3.3 or 3.4 or something like that and RHEL 7.0 currently use 3.10 (a giant leap forward from the 2.6.32 kernel of RHEL 6.x), but there was no way X.org recognized the Hyper-V framebuffer.

With the xorg.conf file gone a long time ago, we are in the era of autoconfig, monitor hotplugging, etc.

Microsoft state that the best way of connecting to a VM running in Hyper-V is via RDP, this requires having a stable network connection between the host and the guest OSs and having a RDP service running in the guest OS: pretty easy on Windows, a bit more complicated on Linux where xrdp, an RDP server, works but it’s not an easy solution and always require a stable network connection.
If the Hyper-V server is in the DataCenter, this surely is the best solution, but on a notebook this is a bit an overkill.

Looking at the output of lsmod, the hyperv_fb module is already loaded, so there is no reason for it not to work.

After following various guides with all the sort of commands, like adding a modeline to xrandr (doesn’t work), adding video=1366×768:24 to the kernel boot arguments (doesn’t work), adding resolution=1366×768 always to the kernel boot arguments (needless to say…), I’ve finally found the first alf of the solution in a forum about SUSE.

TL;DR

Adding in GRUB2 the kernel boot argument:

video=hyperv_fb:1366x768

finally allowed me to use the VM in full screen @ 1366×768!

Bye

Share this:
Share this page via Email Share this page via Stumble Upon Share this page via Digg this Share this page via Facebook Share this page via Twitter

Fahrenheit 896

posted by Viking
apr 13

Paper burns at 451° F (~233° C). Ray Bradbury decided to title one of his novels after this temperature.

Solder melt at 370° F (~188° C). No one titled a novel after this temperature, and the reason is pretty obvious: it isn’t always true.

The most common solder was, when I was small and Xmas trees were tall (Bee Gees anyone?), the alloy made of tin and lead.
More precicely, the alloy made 60% from tin and 40% from lead.
It was cheap, it was good, it was easy to use for the average electronic use, that is building a circuit from scratch or repair a factory-made device (they used more or less the same alloy).

Now we are tall, and Xmas trees are small (“First of May”, by The Bee Gees) and lead is nowhere to be seen anymore. Not in gasoline, nor in solder alloys used in factory-made devices.
The problem is that when a component (maybe a SMD) is soldered on the ground plane of the circuit board with a ROHS-compliant solder, not even 896° F (~480° C) are able to melt the d**n thing!

I will make d**n sure not to buy any ROHS-compliant solder for the following decades.

Bye

Share this:
Share this page via Email Share this page via Stumble Upon Share this page via Digg this Share this page via Facebook Share this page via Twitter


For various reasons, I need to use OpenVPN at the university to be able to connect to the internet when I’m connected to a wired connection.
I don’t like OpenVPN on Windows, primarily because it’s a software created for *nix systems and doesn’t run very well under Windows so it needs a lot of configuration under certain circumstances and so on.
Nevertheless, OpenVPN works by creating an IPv4 Point-to-Point connection using a /30 subnet between the server and the client so, for instance, if the server, on the Point-to-Point connection, has the address 192.168.2.1, the client will have 192.168.2.2, the subnet itself will be 192.168.2.0 and the broadcast address will be 192.168.2.3.

If you’re using Oracle VirtualBox or VMWare Player, you can simply configure the network adapter of the virtual machine to manage a NAT themselves. If the host has internet access, guest operating systems will be able to connect via a NAT hidden to (but usually customizable by) the user.

But what if you’re using Hyper-V? Hyper-V has been designed for datacenter operations on Windows Server, where dedicated physical routers would manage routing, NAT etc.
This brings a lot of really cool features like directly connect a virtual machine to a FCoE SAN or managing virtual switches and other stuffs, as expected from an enterprise-class hypervisor.

Supposing that, like me, you’re running Windows 8 / 8.1 with Hyper-V on a laptop (I need it for the Windows Phone 8 emulator) and you’re connecting using some kind of PtP connection, like OpenVPN or a simple PPPoE modem, you need to configure a NAT on your system.
This despite the fact that you won’t always need it, that will not work for every wireless or wired connection you’re gonna use and that there is a really big problem ahead, but let’s talk about this later.

Creating a NAT for your virtual machines it’s pretty easy.
Just open the Hyper-V management console, create a new virtual switch connected to an internal network (call it “Hyper-V NAT” or something like that), then open the Control Panel, open Network Connection and Sharing Center and enable the Internet Connection Sharing for the PtP connection you’re using and select as the “domestic network” the “Hyper-V NAT” adapter.

By doing this, Windows will enable packet forwarding, will set the IP address of the “Hyper-V NAT” adapter to 192.168.137.1/24 and will enable a DHCP & DNS service on the same adapter.
Virtual Machines connecting via the “Hyper-V NAT” adapter will automatically get their network configuration and will be able to surf the web (and usually download several hundred MBs of updates on their first run).

Seem easy, huh? Well, it is. You can also change the switch to which a VM is connected when it’s running, so if you’re moving to a place when your PtP connection is not needed you can simply connect the VM to another virtual switch.

That’s fine, really fine, until someday you need to share the 3G/4G connection of your Windows Phone 8 with your laptop.
How does it work? Easy. Your WP8 device turns into a wireless router with a built-in DHCP & DNS service.
The Wi-Fi adapter IPv4 address of your WP8 device is set to 192.168.137.1/24 and your laptop will get the network configuration automatically by your phone.
Right?

NO.

Your wireless adapter is set as the following:
IPv4 address: 192.168.137.2 ( or .3, or .42, etc. automatically assigned by DHCP of your Windows Phone)
Subnet Mask: 255.255.255.0 (or /24, by DHCP)
Default Gateway: 192.168.137.1 (by DHCP)

but your “Hyper-V NAT” adapter is set as the following:
IPv4 address: 192.168.137.1 (automatically set by Windows Internet Connection Sharing service)
Subnet mask: 255.255.255.0 (or /24, always assigned by Windows ICS service)
Gateway: none (or 127.0.0.1, but it doesn’t matter).

That’s not gonna work. What your WP doesn’t know is that it’s telling your laptop to use itself as gateway.

The easy workaround is to disable the “Hyper-V NAT” adapter when you’re tethering your connection to your laptop, and that works.

Or, you can choose to solve this problem, by telling Windows ICS to use a different subnet to share the connection.
Because 192.168.137.0/24 is not really an “exotic” subnet, I decided to use the 172.31.137.0/24 subnet (yes, /24, not that you can select a different netmask anyway).
To change these values, you need to manually edit the Registry’s values located in Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters.
Change ScopeAddress, ScopeAddressBackup and StandaloneDhcpAddress accordingly to your needs.

Try to select a subnet you’re almost sure you’ll never use and you should be fine until IPv4 will be deprecated (HAH!).

Have fun!

Bye

Share this:
Share this page via Email Share this page via Stumble Upon Share this page via Digg this Share this page via Facebook Share this page via Twitter

feb 4

Last year I wrote how to create and configure an IPv6 over IPv4 tunnel with Hurricane Electric.
Now I’m gonna write how to configure a Linux host with two NICs as an IPv6 router using an HE tunnel when behind a NAT-router.
The examples here are referred to a Debian 6 Linux distribution and may be sligthly different for other distros or *BSD OSs.

Let’s suppose your current IPv4 network is a classical 172.16.0.0 with a 255.255.0.0 netmask ( /16 in short ), and that your IPv4 NAT-router is located at 172.16.255.254.
The first thing you need to do is to configure one of the interfaces of your IPv6 router, let’s say eth0, with a fixed IPv4 address in the same subnet of your router, like 172.16.255.253.
Then you have to make sure that your NAT-router forward protocol 41 to your IPv6 router. If this is not the case, you can simply put you IPv6 router in the DMZ. Be careful when you do that! Be sure to apply strong IPv4 firewall policies and keep the daemons listening to that interface at the minimum, maybe on non-standard ports.
After configuring the IPv6 router default IPv4 route ( to your NAT-router of course ), test if you can reach an address outside the local subnet, like 8.8.8.8 ( Google Domain Name Server ).
You’ll also like to assign an IPv4 address to the other network interface, for instance eth1, to allow some daemons to listen to an IPv4 local address ( like sshd or named for IPv4 ).

Debian and other Debian-related distros usually store the network configuration inside the /etc/network/interfaces file.

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
   address 172.16.255.253
   netmask 255.255.0.0
   gateway 172.16.255.254

auto eth1
iface eth1 inet static
   address 172.16.255.252
   netmask 255.255.0.0

In the tunnel configuration page on the HE’s website you can find the routable /64 subnet. Mind the difference between the tunnel IPv6 addresses, that usually are something like 2001:1234:5678:abc::1 and 2001:1234:5678:abc::2, and your routable IPv6 subnet that will be something like 2001:1234:5679:abc::.
The IPv6 address of eth1 is static ( this is a router after all ) and  must belong to your routable subnet. You can choose of using a simple address, like 2001:1234:5679:abc::1, or, if you’re a bit paranoic, you can randomize it to something like 2001:1234:5679:abc:5f32:9b8c:d12e:15fa.
Because your routable subnet is not gonna change unless you destroy your HE’s tunnel and create a new one, you can configure the eth1 IPv6 address as static and put the configuration inside /etc/network/interfaces, by adding the following lines:

iface eth1 inet6 static
   pre-up /sbin/ip6tables-restore < /etc/iptables/ipv6firewall
   address 2001:1234:5679:abc:5f32:9b8c:d12e:15fa
   netmask 64

The second line is needed to enable the ip6tables firewall.

The configuration for ip6tables is based on a more or less ‘standard’ requirement: all the hosts behind the router have unlimited access to the internet on every protocol or port while they’re not reachable from the rest of world with the exception of some ICMPv6 messages.
Just to avoid some types of DOS attack, I’ve decided to limit the amount of ICMPv6 echo requests the router ( and the network behind ) is gonna receive.
The content of the /etc/iptables/ipv6firewall file is the following:

# Generated by ip6tables-save
*filter
:INPUT DROP [23:2392]
:FORWARD DROP [4:320]
:OUTPUT ACCEPT [30:2888]
-A INPUT -i lo -j ACCEPT
-A INPUT -i sit1 -p ipv6-icmp --icmpv6-type echo-request -m limit --limit 5/sec -j ACCEPT
-A INPUT -i sit1 -p ipv6-icmp --icmpv6-type echo-request -j DROP
-A INPUT -i sit1 -p ipv6-icmp -j ACCEPT
-A INPUT -i eth1 -j ACCEPT
-A INPUT -i sit1 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o sit1 -j ACCEPT
-A FORWARD -i sit1 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i sit1 -p ipv6-icmp --icmpv6-type echo-request -m limit --limit 5/sec -j ACCEPT
-A FORWARD -i sit1 -p ipv6-icmp --icmpv6-type echo-request -j DROP
-A FORWARD -i sit1 -p ipv6-icmp -j ACCEPT
COMMIT

Then you need to enable IPv6 forwarding at boot time by putting the following file ( you can name it as you want, as long as it ends with .conf; I’ve called it ipv6_forwarding.conf ) inside the /etc/sysctl.d/ directory:

# /etc/sysctl.d/ipv6_forwarding.conf

net.ipv6.conf.all.forwarding = 1

The next thing to configure is the router advertisement daemon, that can be installed ( as root ) using the command:

# apt-get install radvd

The configuration file is /etc/radvd.conf and should be similar to this one:

interface eth1
{
   AdvSendAdvert on;
   AdvManagedFlag on;
   MinRtrAdvInterval 5;
   MaxRtrAdvInterval 15;
   AdvLinkMTU 1280;
   prefix 2001:1234:5679:abc::/64
   {
   };
};

Some flags are required ( like ‘AdvLinkMTU’ set to 1280 ) for the tunnel to work, some are optional ( like ‘AdvManagedFlag’ ). Maybe next time I’ll wrote how to configure a DHCPv6 server. DHCPv6 is a little more complex than DHCPv4 also because it must be deployed side-to-side with router advertisement, but allows far greater flexibility than its IPv4 counterpart.
In the meantime, with IPv4-reachable nameservers answering with AAAA records, there’ll be no real need for IPv6-reachable nameservers on the short term ( that is, until IPv4 will be the mainstream protocol ).

The last part is to set up the tunnel using a shell script. Actually, two scripts are used. The first one contains only variables like the username, the tunnel ID and the password that should be passed via http on SSL to configure the firewall at Hurricane Electric and tell it our public IP.
The file I created is named HE_personal.sh and is stored inside /root with 0700 permission. The content is the following:

#!/bin/sh

USERNAME=■■■■■■■■
PASSWORD=■■■■■■■■
TUNNELID=■■■■■■■■

The other file is HE_tunnel_setup.sh that contains the real commands needed to create the tunnel. I’ve decided to launch it manually ( must be executed as root ) but you can decide to launch it at boot time writing an init.d script or by simply using another ‘pre-up’ directive in /etc/network/interfaces. The content is the following:

#!/bin/sh

. /root/HE_personal.sh

rm ipv4_end.php*
wget --no-check-certificate https://$USERNAME:$PASSWORD@ipv4.tunnelbroker.net/ipv4_end.php?tid=$TID

ifconfig sit0 up
ifconfig sit0 inet6 tunnel ::123.45.678.90
ifconfig sit1 up
ifconfig sit1 inet6 add 2001:1234:5678:abc::2/64
route -A inet6 add ::/0 dev sit1

The –no-check-certificate flag for wget is needed because of a little issue with an HE’s SSL certificate. Mind the prefix of the sit1 interface and the remote endpoint of the IPv4 tunnel.

After rebooting the IPv6 router, ip6tables and radvd should be already up and running. After launching the script the tunnel should be configured without issuing any other command.

To check if the hosts had received an IPv6 Link-Global address you can use:

$ ifconfig -a

under any UNIX, Unix-like or Linux operating system or

> ipconfig /all

under Windows ( any version after Windows XP SP0 ).

Then you can test if the hosts can reach the IPv6 internet using ping6 under any UNIX, Unix-like or Linux operating system ( excluding Oracle Solaris ) or using ping under Windows or Solaris.

Bye

Share this:
Share this page via Email Share this page via Stumble Upon Share this page via Digg this Share this page via Facebook Share this page via Twitter


Last night I wanted to try something new on Mirage, my Sun Ultra 5. After changing the configuration of the SCSI disks, moving some drives between the two channels of the controller ( and changing the correspondingly devaliases in the NVRAM with several nvunalias / nvalias commands ), I thought about installing NetBSD-current ( currently 5.99.55 ).

This wiki list a serie of commands that would compile and install NetBSD-current assuming that a release of NetBSD is already running. So because I already had a NetBSD 5.1 running on Mirage, I thought of following the “short way”… only to find out that fetching the sources via anoncvs took nearly 4 hours. I’m not blaming anoncvs, because trying to fetch the tarball and extracting all the files took nearly 2 hours two days later.

Now, the most “interesting” thing is that the build script, before compiling the kernel and the userland, need to compile the compiler, because NetBSD 5.99 need GCC 4.5 compiled for the target architecture ( in this case, sparc64 ).
I was just thinking to stay with 5.1 ( losing some opportunity offered by current, like some ZFS support etc. ), when I tought about doing some test on a VM in VirtualBox. During the installation process I choose to get the sets ( a bunch of tgz files ) from http rather than from the CD. Looking at the options for the http install, I tought of doing something “nasty”:

using the 5.1 installer to install 5.99.

It’s longer to explain than actually doing it, but this is possible because on the nyftp http mirror ( http://nyftp.netbsd.org/ ) inside the pub/NetBSD-daily/HEAD/ directory are stored the last five build of NetBSD-current. Inside each directory ( named after the date and time of build ), there are the directories for each architecture, containing the binary sets ( the bunch of tgz files ) that will be used from the installer.
So, after changing the options in the installer accordingly to what is needed, the installation can start and will end with only two minor problems.

The first one is that it’s not possible to set the root password, the second is that the rc_configured variable in /etc/rc.conf will not be changed by the setup program, resulting in a single user boot after reboot, with the root filesystem mounted in read-only.
But these are problems that even a NetBSD newbie know how to solve ( If someone is interested in something like NetBSD-current, then a basic knowledge of vi and of the standard UNIX commands, like mount or passwd is take for granted ).

Mirage is now running NetBSD-current with a LVM volume ( not as powerful as ZFS but require a lower overhead ) in the Sun StorEdge FlexiPack 599, and has been configured as a NFS ( Nightmare Network File System ) Server.

Bye

Share this:
Share this page via Email Share this page via Stumble Upon Share this page via Digg this Share this page via Facebook Share this page via Twitter


This article is a sort of “Post-it®”, a brief explanation of how to configure a network bridge with two NICs under CentOS 5.x / 6.x. After spending more than 10 minutes googling how to perform this task ( mainly reading about ( l ) users that didn’t have a clue about what a network bridge is or, worse, asking how to bridge n-thousand VM while performing routing having iptables misconfigured… ), I thought it was better to write everything down in “safe place”: what’s better than my blog?

So, this is how I have made the bridge on Nighthawk ( a double Pentium III – 800 MHz with a Gig of RAM and a pair of UWSCSI3 disks ), under CentOS 6.0.
The two NICs are both based on an Intel 82559 chip. The first one is integrated into the motherboard, while the second one is on a PCI slot.

OBVIOUSLY, a network bridge has ONE MAC address ( could be the same of one of the two NIC or could be a different one ) and ONE IP address, unless your playing with aliased interface over a bridge, but this is not the case.

The integrated NIC is eth0, the NIC on the PCI slot is eth1 while the network bridge is nbr0.

So, these are the configuration files:

# /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE="eth0"
HWADDR="00:30:48:AA:BB:CC"
ONBOOT="yes"
BRIDGE="nbr0"

# /etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE="eth1"
HWADDR="00:90:27:DD:EE:FF"
ONBOOT="yes"
BRIDGE="nbr0"

# /etc/sysconfig/network-scripts/ifcfg-nbr0
DEVICE="nbr0"
TYPE="bridge"
BOOTPROTO="dhcp"
IPV6INIT="yes"
IPV6_AUTOCONF="yes"
ONBOOT="yes"

The bridge takes its IP address via DHCP. If a static address is required, file ifcfg-nbr0 must be changed according to what is reported into the RHEL Deployment Guide.

Bye

Share this:
Share this page via Email Share this page via Stumble Upon Share this page via Digg this Share this page via Facebook Share this page via Twitter