Posts Tagged ‘linux’

Cubieboard as NetFlow collector with nfsen

Friday, June 28th, 2013

One month ago I bought a cubieboard to have a small, powerfull, unexpensive, low noise, low power consumption linux server at home, for my nerd projects.

The first project I started ? Run a NetFlow collector at home for my Ninux nodes.

The Cubieboard

The cubieboard is a small ARM pc. With 1Ghz processor and 1Gb of RAM is very flexible for any application. I bought it from miniand.com with the developer kit and I also got from Amazon a USB power adapter and a SD memory card. A few weeks after the new Cubieboard A20 came out ! So I suggest you get the new one even if it cost some dollars more, because it has a dual core CPU.

(more…)

IPV6 + OpenWRT + UCI + ADSL Telecom HowTo

Friday, November 2nd, 2012

In questi giorni di festa mi sono cimentato ad un upgrade dell’harware di rete a casa dei miei genitori. Avendo messo un router con Openwrt ho provato ad usare il collegamento IPV6 nativo della rete Telecom e la cosa bella è che ha funzionato!

Screenshoot Luci interface

Visto che in rete si trova una guida per router Fritz!box e router Cisco ho deciso di scrivere queste due righe per fare la medesima configurazione con OpenWrt.

La configurazione hardware è costituita da router tplink TL-WR1043ND con openwrt (Attitude Adjustment 12.09-beta) a cui è collegato un modem adsl sulla porta wan. Considerando che i modem puri vanno scomparendo è anche possibile usare un router adsl economico con firmware originale e usarlo come modem impostandolo in modalità “bridge” . Il collegamento verso il provider avviene tramite pppoe, ecco la sezione relativa del file /etc/config/network

config interface ‘wan’
option _orig_ifname ‘eth0.2’
option _orig_bridge ‘false’
option proto ‘pppoe’
option ifname ‘eth0.2’
option username ‘adsl@alice6.it’
option password ‘IPV6@alice6’
option ipv6 ‘1’
option mtu ‘1492’
option metric ‘100

 

La configurazione software si basa sull’utilizzo di wide-dhcpv6-client e radvd. Come funziona: il client dhcp6c riceve la delega per un /64 , imposta le interfacce locali del router e scrive il prefisso ottenuto nel file /var/etc/radvd.conf in modo tale che radvd possa mandare i RA sulla rete locale.

Una volta istallati i package (opkg install wide-dhcpv6-client radvd) si configurano. Ecco i miei file.

/etc/config/config/dhcp6c

‘dhcp6c’ ‘basic’
option ‘enabled’ ‘1’                            # 1 = enabled; 0 = disabled
option ‘interface’ ‘wan’                        # This is the interface the DHCPv6 client will run on
option ‘dns’ ‘dnsmasq’                          # Which DNS server you run (only dnsmasq currently supported)
option ‘debug’ ‘1’                              # 1 = enable debugging; 0 = disable debugging

# Send options (1 = send; 0 = do not send)
option ‘pd’ ‘1’                                 # Prefix Delegation
option ‘na’ ‘1’                                 # Non-Temporary Address
option ‘rapid_commit’ ‘1’                       # Rapid Commit

# Request options (1 = request; 0 = do not request)
option ‘domain_name_servers’ ‘1’
option ‘domain_name’ ‘0’
option ‘ntp_servers’ ‘0’
option ‘sip_server_address’ ‘0’
option ‘sip_server_domain_name’ ‘0’
option ‘nis_server_address’ ‘0’
option ‘nis_domain_name’ ‘0’
option ‘nisp_server_address’ ‘0’
option ‘nisp_domain_name’ ‘0’
option ‘bcmcs_server_address’ ‘0’
option ‘bcmcs_server_domain_name’ ‘0’

# Override the used DUID, by default it is derived from the interface MAC
# The given value must be uppercase and globally unique!
#option ‘duid’ ’00:03:00:06:D8:5D:4C:A5:03:F2′

# Script to run when a reply is received
option ‘script’ ‘/usr/bin/dhcp6c-state’

# Define one or more interfaces on which prefixes should be assigned
config ‘interface’ ‘loopback’
option ‘enabled’ ‘0’                            # 1 = enabled; 0 = disabled
option ‘sla_id’ ‘0’                             # Site level aggregator identifier specified in decimal (subnet)
option ‘sla_len’ ‘0’                            # Site level aggregator length (64 – size of prefix being delegated)

config ‘interface’ ‘lan’
option ‘enabled’ ‘1’
option ‘sla_id’ ‘1’
option ‘sla_len’ ‘0’

Come potete vedere l’unica interfaccia che ottiene l’IPV6 è la lan. In realtà ho provato ad fare in modo che anche la porta WAN abbia un IPV6 ma essendo l’interfaccia nello stato “UNKNOW” invece che “UP” dhcpv6c non gli fornisce un ipv6 global, comunque il routing è garantito da indirizzi link (classe fe80::) tra il router e il provider.

L’altro file da configurare è /etc/config/radvd

config interface
option interface        ‘lan’
option AdvSendAdvert    1
option MinRtrAdvInterval 3
option MaxRtrAdvInterval 10
option AdvLinkMTU 1280
option AdvManagedFlag   0
option AdvOtherConfigFlag 0
list client             ”
option ignore           0

config prefix
option interface        ‘lan’
# If not specified, a non-link-local prefix of the interface is used
list prefix             ”
option AdvOnLink        1
option AdvAutonomous    1
option AdvRouterAddr    1
option ignore           0

config route
option interface        ‘lan’
list prefix             ”
option ignore           0

Una volta avviato il tutto vi dovreste trovare il file generato /var/etc/radvd.conf che assomiglia a questo:

interface br-lan
{
MaxRtrAdvInterval 10;
MinRtrAdvInterval 3;
AdvLinkMTU 1280;
AdvSendAdvert on;
AdvManagedFlag off;
AdvOtherConfigFlag off;

prefix 2a01:2003:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx/64
{
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr on;
};
};

That’s all folk

FaByS

 

Aggiornamento 26/04/2014

Avendo creato un nodo ninux dove è presente questo router, dopo aver cambiato delle configurazioni sul firewall tutto il meccanismo a cominciato a non funzionare più. O meglio l’ipv6 il router l’otteneva ma il dhcp6c non scriveva correttamente il prefisso nel file /var/etc/radvd.conf. Solo un laconico messaggio nel syslog: ” client6_recvreply: got an expected reply, sleeping.”

Riavviando a mano il dhcp6c tutto tornava a funzionare. Non riuscendo a venirne a capo ho optato per un workaround: uno script eseguito dal crontab che fa il check della configurazione ogni 5 minuti e se non trova il prefisso lo riavvia.

Lo script è il seguente:

 

 

#!/bin/ash
if [ `cat /var/etc/radvd.conf | grep prefix | wc -l` -eq 0 ]; then /etc/init.d/dhcp6c restart; echo “ipv6 Workaround” >> /var/log/ninux.log ; fi

Ninux al LUG di Tor Vergata

Friday, December 30th, 2011

Orazio e Clauz il 16 dicembre hanno presentato Ninux all’evento di inaugurazione del roma2lug.
Sono molto giovani e ci sono piaciuti! Sembravano anche molto
interessati a Ninux…  a Clauz gli hanno detto se possono approfondire la parte tecnica … vi aspettiamo al Fusolab al Giovedi’ Nerd 🙂

 

GSoC 2011: L-VN Lite Virtual Network

Monday, September 5th, 2011

L-VN is a tool for overlay network creation based on IP in UDP encapsulation performed in Kernel space without encryption/authentication of the tunneled packets. The idea of L-VN is to exploit the IP/UDP encapsulation kernel module proposed for GSoC 2010  to develop a VPN/Overlay tool based on IP/UDP encapsulation performed in kernel space with no “security services” for the encapsulated packets (i.e. no confidentiality, no authentication). The goal is to provide a lightweight overlay network tool that might be preferable to other VPN/Overlay solutions for devices with limited computational resources. The project is a Freifunk-Ninux.org proposal, and is sponsored by the Google Summer of Code 2011 program.

L-VN consists of 3 main elements:

  1. IPUDP encapsulation module: is a kernel module that exports a virtual network devices that perform ip-udp encapsulation. Packets routed through this network interfaces will be encapsulated in IP/UDP headers and sent to the proper tunnel endpoint.  As to the current status, ipudp module provides 2 virtual devices modes:  A) FIXED mode: a single ipudp tunnel is bound to a virtual ipudp device. This type of virtual interface is double-stack, in the sense that we can assign both IPv4 and IPv6 address to the device and use it for both IPv4 and IPv6 applications. B) MULTI_V4 mode: multiple ipudp tunnels can be bound to this type of virtual interface. For each encapsulated packet, the proper tunnel is chosen by a set of rules that bind the destination IP address of the inner packet, with a given tunnel. For GSoC2011 the module has been updated to be compatible with kernel 2.6.38 and modified in different points to implement the keepalive mechanism.
  2. IPUDP configuration tool: this tool can be compiled as both program or library and provides a set of primitives based on NETLINK sockets to configure the IPUDP encapsulation module. IPUDP_CONF provides the necessary primitives for addition/removal of virtual network devices, ipudp tunnels and forwarding rules.
  3. IPUDP signaling agents: a client and a server program written in C for automatic tunnel establishment and management. In details, these components provides the following services: a) mutual authentication based on X509 certificates and TLS (openssl); b) NAT reflexed address discovery and automatic tunnel establishment; c) NAT binding keep alive; d) automatic inactive tunnel de-allocation. This component has been completely implemented for GSoC2011 but it still needs some work.

The code is available through the ninux SVN repository, at the path: https://svn.ninux.org/svn/ninuxdeveloping/ipudp/v02. Comments, remarks or any kind of support will be truly appreciated.

Contacts: marco.bonola@uniroma2.it, marco.giuntini@uniroma2.it

 

Linux Day: ZioPRoTo in trasferta a Firenze a parlare di Ninux

Monday, October 18th, 2010

Finalmente un po’ di attività Nerd ! :)

Questo weekend in tutta Italia ci sarà il Linux Day. In quasi tutte le città l’iniziativa si tiene sabato 23 (come a Roma ad esempio), ma in alcuni luoghi dove i LUG (Linux user group) sono particolarmente attivi, tutto il weekend è dedicato al Kernel con il famoso pinguino.

Io sarò a Firenze, dove il venerdì parlerò di Ninux al Festival della Creatività 2010, ed il Sabato parlerò di IPv6 al Linux Day del FLUG. Dopo aver conosciuto Leandro del FLUG all’hackmeeting romano, vado con piacere in trasferta in Toscana a parlare di reti wireless comunitarie. Magari dopo l’esperienza di Pisa potrebbe essere Firenze la prossima città ad essere invasa dai routers di Ninux ! :)

Saverio