Technicolor TG582n IPv6 for Forthnet

ipv6_logo

So, after a long time of zero blog posting activity I thought it would be nice to share my ADSL modem/router configuration for IPv6 connectivity with my current ISP, Forthnet.

The ADSL router I use is a Forthnet provided Technicolor TG582n. TG582n’s firmware revision is at *10.2.2.B.EH*. I am already aware of my provider’s IPv6 settings so that really helped me a lot with the evaluation of my setup. For more information regarding Forthnet’s IPv6 setup status and/or settings you can refer to it’s official website. According to the site, Forthnet has currently configured almost all of its ADSL BRAS Routers so you don’t have to alter your PPP username to have IPv6 up and working.

Anyway, let me guide you through my TG582n configuration which works in perfect harmony with Forthnet’s IPv6 settings.

First, login into the CLI of the modem/router. As usual, TG582n’s default IP address is 192.168.1.254.

telnet 192.168.1.254

Enable ipv6 on the Internet ppp interface

:ppp ifdetach intf Internet
:ppp ifconfig ipv6 enabled intf Internet
:ppp attach intf Internet

Re-configure the IPv6 DHCP Client of the modem/router to work correctly with Forthnet’s IPv6 routers.

:dhcp clientv6 ifdetach intf=Internet
:dhcp clientv6 ifconfig intf Internet listenra disabled
:dhcp clientv6 ifattach intf=Internet

You will know if everything worked correctly when you receive your /56 IPv6 Prefix. You can check it with the following command

:dhcp clientv6 iflist expand enabled

See an output example bellow:

DHCPv6 Client Info :
Interface : Internet
Mode : stateful
DHCPv6 Client State : [BOUND]
Client DUID :
Non Temporary Adress list :
Prefix list :
IA ID :
Renew value : 0 days, 12:00:00
Rebind value : 0 days, 19:12:00
Prefix : ::/56 [active]
Preferred lifetime : 1 day, 0:00:00
Valid lifetime : 7 days, 0:00:00

Timeout till depreferred : 0 days, 18:41:58

Configure modem/router’s IPv6 DHCP Server in order to pass out correct DNS options on your local LAN

:dhcp serverv6 config state=enabled
:dhcp serverv6 option add name=forthnet_dns
:dhcp serverv6 option fieldadd name=forthnet_dns option=domain-name-servers value=2a02:2148:99:8888::8888
:dhcp serverv6 option add name=google_dns
:dhcp serverv6 option fieldadd name=google_dns option=domain-name-servers value=2001:4860:4860::8888
:dhcp serverv6 pool optionadd name=LAN6_pool optionname=forthnet_dns
:dhcp serverv6 pool optionadd name=LAN6_pool optionname=google_dns

That would be all!

You can now enable the IPv6 settings on one of your local workstations and check if everything is working correctly. Forthnet has an IPv6 testing website to check from your web browser: http://test-ipv6.forthnet.gr/

Have fun with your IPv6 Home setup! :)

Mozilla Firefox OS App Days in Greece

Firefox OS


As scheduled by Mozilla
, on 26/01/2012 Firefox OS was showcased worldwide receiving quite possitive feedback. Athens, Greece was one of the cities to be in the list so an all day event took place under the supervision and great care of people involved directly or indirectly with the project itself. With help from @ppapadeas, @comzeradd, @bacharakis and many other members of Mozilla’s Greek Community (@MozillaGreece) as well as Greek FOSS supporters, we experienced the new mobile operating system in full action!

The event started early in the morning with an overall description of Firefox OS’s features and strenghts. An OS running on rock solid and well tested technologies such as HTML5, CSS3 and Javascript is here to offer a practically transparent platform for your Web Apps to run natively on any supported mobile device. Best part? Mozilla provides free tools for all developers to create, test, publish and even monetize from their mobile applications through the Firefox Marketplace.

After the initial session, a “Create your Own Firefox OS Web App” hackathon started with almost all the participants taking place. Everyone got their hands on Firefox OS Simulator -try it with the latest Firefox browser, very slick add-on for developers- and tested the product. During the hackathon and almost every hour, lightning talks were taking place covering more advanced concepts of mobile application development such as responsive UI, Git code versioning and best of all, flashing existing Android devices with Mozilla’s new Firefox OS!

The event ended with a presentation of all mobile applications created throughout the hackathon. Each project received a Firefox OS Phone for Developers, a nice gift from Geeksphone. Geeksphone is soon launching 2 different flavors of Firefox OS Dev Phones in the market and the devices will be built according to the new OS’s features and needs.

Check #FirefoxOSAppDays and follow @MozillaGreece on Twitter to receive the latest updates.

Firefox OS App Days

UDP / TCP Checksum errors from tcpdump & NIC Hardware Offloading

vector_tux.864e6cdcc23e

If you’ve ever tried to trace a UDP or TCP stream by using the tcpdump tool on Linux then you may have noticed that all, or at least most, packets indicate checksum errors. This is caused because you have checksum offloading on your network card (NIC) and tcpdump reads IP packets from the Linux kernel right before the actual checksum takes place in the NIC’s chipset. That’s why you only see errors in tcpdump and your network traffic works ok.

So, just to prove my point, here is a tcpdump output while monitoring DNS traffic (udp/53)

$ sudo tcpdump -i eth0 -vvv -nn udp dst port 53
 tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
 17:04:48.145904 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 61)
 10.0.0.2.56497 > 10.0.0.1.53: [bad udp cksum 0x8f54 -> 0xb8fc!] 30234+ AAAA? www.twitter.com. (33)
 17:04:48.145925 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 61)
 10.0.0.2.56497 > 10.0.0.1.53: [bad udp cksum 0x224d -> 0x2604!] 30234+ AAAA? www.twitter.com. (33)

After checking active NIC hardware offloading options you can see the obvious

$ sudo ethtool -k eth0 | grep on
 rx-checksumming: on
 tx-checksumming: on
 scatter-gather: on
 generic-segmentation-offload: on
 generic-receive-offload: on
 rx-vlan-offload: on
 tx-vlan-offload: on

After disabling TCO (tcp offloading) for TX/RX on the NIC the problem is gone

$ sudo ethtool -K eth0 tx off rx off

$ sudo tcpdump -i eth0 -vvv -nn udp dst port 53
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
17:06:09.355411 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 57)
10.0.0.2.18964 > 10.0.0.1.53: [udp sum ok] 292+ AAAA? twitter.com. (29)
17:06:09.355431 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 57)
10.0.0.2.18964 > 10.0.0.1.53: [udp sum ok] 292+ AAAA? twitter.com. (29)

 

For the sake of performance, remember to turn TCO back on after each tcpdump execution. ;-)

If you saved the tcpdump output and later you need to correct the bad checksums then you can do one of the following:

$ sudo tcpreplay -i eth0 -F -w output.cap input.cap

or

$ sudo tcprewrite -i input.cap -o output.cap -C

Edit:
In this excellent article you can see the whole process illustrated as well as the impact of Generic Segmentation Offloading during packet capture.

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close