MavEtJu's Distorted View of the World - FreeBSD

How I killed 13 500 000 pages in the Google search engine
Sawtooth on a Raspberry Pi
FreeBSD laptop as a Wireless Access Point for an iPhone
Coding Styles
FreeBSD - Cutting down
Updated iPhone apps
The FreeBSD Project app
FreeBSD TFTP server and client updated
tzdata2010b - FreeBSD users in Mexico, heads up!
Internode IPv6 over ADSL project
tzsetup(8) changes
Localisation in the FreeBSD operating system: share/{monet,msg,numeric,time}def
Huawei E169 on 7-STABLE
Huawei E169 statistics
FreeBSD - import of tzcode2009e
FreeBSD and the Huawei E169 USB 3G Modem - Step two
FreeBSD and the Huawei E169 USB 3G Modem - Step one
iPod A1285 and FreeBSD happiness
HAMMER File System (not) on FreeBSD
src/share/zoneinfo updated to 2008h
BUGS and FreeBSD Goodies
src/share/zoneinfo updated to 2008g
FreeBSD and contributed code.
src/share/zoneinfo updated to 2008f
Strange PXE Booting
Network Administration with FreeBSD 7
FreeBSD mirrors Spring cleanup!
Internode to support IPv6 tunneling (and more)
When things you wrong, you want useful error messages
Migrating from i386 to amd64 - ldd(1) on 32 bit objects
CVSROOT-ports/modules re-animated
Using the Internode SourceForge mirror
FreeBSD IPv6 Divert socket adventures (3)
FreeBSD IPv6 Divert socket adventures (2)
FreeBSD IPv6 Divert socket adventures
Three Mobile roaming 3G network
src/share/zoneinfo updated to 2008b
src/share/zoneinfo updated to 2008a
New tftp / tftpd implemetation for FreeBSD
src/share/zoneinfo updated to 2007k
Getting rid of unused shared memory segments, message queues and semaphore sets - ipcrm(1)
FreeBSD and the Huawei E220 USB 3G Modem
FreeBSD FTP mirrors quality
src/share/zoneinfo updated to 2007j
tftpd -W option
HP DL380 Raid Controller Disk issues.
FreeBSD For All podcast has disappeared
FreeBSD Multimedia Resources list has moved
/etc/resolv.conf in jails
FreeBSD Multimedia Resources list
FreeBSD and Citrix MetaFrame
When routing goes bad....
Sound hickups during disk access
Multiple applications accessing /dev/dsp under FreeBSD
Upgrading via cvsup

Back to index

How I killed 13 500 000 pages in the Google search engine

Posted on 2014-04-04 08:00:00
Tags: FreeBSD

Talk about a loaded title, en par with the quality (or lack there of) of the various click bait titles on the postings I see on Facebook and friends...

I was told by my hosting provider that my index to the FreeBSD mailinglists at http://www.mavetju.org/mail/ was using more bandwidth alone than all of their public websites together. Now this is not much of a record, since they have only low-bandwidth websites, but still...

Looking through the logs, I saw that the Googlebot and the Bingbot and some bot from China were happily fighting over CPU and bandwidth to index all of the files. Going at it on a speed of about 50 requests per seconds for 24 hours per day.

So what could I do? Checking in Google for site:mavetju.org/mail/, I saw that there were about 13 500 000 pages indexed. For what goal? Not much anymore, I have stopped following all except the FreeBSD Announcement mailinglists a couple of years ago. I still use it on my laptops, but that is all.

So... That mailinglist archive has been shut down. You can still find the cached version of it in Google by using the above search terms, but that will disappear too.

And that is the story on how I killed 13 500 000 pages in Google. I wonder how much many computers in their data center that frees up for other things. Probably none...

No comments | Share on Facebook | Share on Twitter

Sawtooth on a Raspberry Pi

Posted on 2013-07-08 08:00:00
Tags: FreeBSD, ARM, Networking

Recently I have obtained two Raspberry Pi units, just to see what can be done with them. So far I'm impressed, this little device is pretty powerful with regarding to video. Being a network guy, this doesn't interests me very much. But as a replacement of a 150 dollar Serial-over-TCP unit it would be very handy to get a serial console on devices it is required for.

First thing, this device runs with an ARM processor, something I haven't played with before on system administration level. First I had to build a FreeBSD ARM based kernel and world and that failed dramatically on my FreeBSD 9.1 i386 based machines. So VirtualBox to the rescue, and on an 64 bit machine it compiled a 10-Current world. My first cross-build was successful!

This disk for the Raspberry Pi is just a flash card, so I had to build an boot image (that was easy), download it to the host of the VirtualBox service (that was easy) and tell somehow OSX to not mount the disk anymore but also to keep it available for me to use dd on. That was tricky, but nothing Google couldn't tell me.

Then the final moment: Boot the Raspberry Pi with FreeBSD and... It worked. How undramatic. Ping the router, ping something on the Internet. All fine.

Except that the RTT for the ICMP packets didn't make sense:

64 bytes from 192.168.123.231: icmp_seq=22 ttl=64 time=1.321 ms
64 bytes from 192.168.123.231: icmp_seq=23 ttl=64 time=10.312 ms
64 bytes from 192.168.123.231: icmp_seq=24 ttl=64 time=9.328 ms
64 bytes from 192.168.123.231: icmp_seq=25 ttl=64 time=8.335 ms
64 bytes from 192.168.123.231: icmp_seq=26 ttl=64 time=7.411 ms
64 bytes from 192.168.123.231: icmp_seq=27 ttl=64 time=6.448 ms
64 bytes from 192.168.123.231: icmp_seq=28 ttl=64 time=5.497 ms
64 bytes from 192.168.123.231: icmp_seq=29 ttl=64 time=4.508 ms
64 bytes from 192.168.123.231: icmp_seq=30 ttl=64 time=3.540 ms
64 bytes from 192.168.123.231: icmp_seq=31 ttl=64 time=2.588 ms
64 bytes from 192.168.123.231: icmp_seq=32 ttl=64 time=1.635 ms
64 bytes from 192.168.123.231: icmp_seq=33 ttl=64 time=0.738 ms
64 bytes from 192.168.123.231: icmp_seq=34 ttl=64 time=9.770 ms
64 bytes from 192.168.123.231: icmp_seq=35 ttl=64 time=8.805 ms
64 bytes from 192.168.123.231: icmp_seq=36 ttl=64 time=7.833 ms
64 bytes from 192.168.123.231: icmp_seq=37 ttl=64 time=6.843 ms
64 bytes from 192.168.123.231: icmp_seq=38 ttl=64 time=5.869 ms

That is a beautiful sawtooth, but that doesn't make sense.

I tried various things, like setting the tick interval from 100 to 1000 Hz, but no luck yet. Together with Peter Jeremy we are looking for an answer, but being a non-kernel guy there is not much what I can do here except test patches.

Show comment | Share on Facebook | Share on Twitter

FreeBSD laptop as a Wireless Access Point for an iPhone

Posted on 2011-01-12 18:00:00
Tags: FreeBSD, 3G, Networking, Free Internet, iPhone

Recently I was on a holiday where the provider of my iPhone had no signal, but where the provider of my 3G modem for the laptop did have a signal. At least my glass was half-full!

In the past I have tried to setup Bluetooth between my laptop and my iPhone, and that resulted in a night of hard work and no effort. This time I tried a different approach: Instead of using Bluetooth for communication, I transformed the FreeBSD laptop into a wireless access point.

The command to change the wireless card from a normal client to a wireless access point are:

[~] edwin@lappie>cat wlan-iphone
#!/bin/sh

ifconfig wlan0 destroy
ifconfig wlan0 create \
	wlandev ath0 \
	wlanmode hostap \
	bssid \
	authmode open \
	ssid "My iPhone WiFi"

ifconfig wlan0 up
ifconfig wlan0 inet 10.0.0.1 netmask 255.255.255.0
sleep 1

sysctl -a net.inet.ip.forwarding=1

service isc-dhcpd restart

Notes:

Experiment with the "open" authmode before you set it to a more secure alternative. Get things working first, then secure then properly.
The interface "ath0" is the Atheros wireless interface of this laptop.

The 3G connection is setup via ppp(8) and to enable NAT on the outgoing packets, you need to enter the following command or add it to the right label in your ppp.conf:

ppp ON lappie> dial
Ppp ON lappie>
PPp ON lappie>
PPp ON lappie> Warning: 0.0.0.0/0: Change route failed: errno: No such process
PPP ON lappie> nat enable yes
PPP ON lappie>

And to make sure that the connected clients get their IP address, you should run the ISC DHCP server with for example the following configuration:

option domain-name "";
option domain-name-servers 8.8.8.8;

default-lease-time 150;
max-lease-time 300;

ddns-update-style none;

authoritative;

log-facility local7;

subnet 10.0.0.0 netmask 255.255.255.0 {
        range 10.0.0.10 10.0.0.99;
        option routers 10.0.0.1;
}

Notes:

8.8.8.8 is the Google DNS server.

Everything is working now, your glass is full again! :-)

Show comment | Share on Facebook | Share on Twitter

Coding Styles

Posted on 2010-12-01 23:00:00
Tags: Coding, Rant, FreeBSD

Recently I stumbled over this piece of code:

if(pinfo->cinfo) {
	if (pinfo->cinfo->col_first[COL_INFO]>=0){
		for (i = pinfo->cinfo->col_first[COL_INFO]; i <= pinfo->cinfo->col_last[COL_INFO]; i++) {

and it nearly made me cry. How many different coding styles can you find in here?

No space between "if" and "(" on the first line.
Space between "if" and "(" on the second line.
Space between ")" and "{" on the first line.
No space between ")" and "{" on the second line.
Pointer check without a "!= NULL" on the first line.
No space before and after ">=" on the second line.
Spaces before and after "<=" on the third line.

This inconsistent coding style drives me craaaaaazy! I am so glad that the FreeBSD Project has a consistent coding style for their own source code.

No comments | Share on Facebook | Share on Twitter

FreeBSD - Cutting down

Posted on 2010-08-27 18:00:00
Tags: FreeBSD

It has been two years since I had a fleet of FreeBSD machines under my control. It has been two months since I lost the videocard of my FreeBSD desktop at home. It has been a good year since something went wrong with the hardware on my laptop and X caused it to hang very fast. It has been a good couple of months, actually since I bought an iPhone and a Mac mini, that I did some FreeBSD development at home. I don't read the mailinglists anymore, I rarely answer emails in relation to it anymore, I haven't visited the IRC channels in months. I think that it is a past station for me.

Completely? No. I still use it on my laptop, in console mode, while traveling from home to work and vice verse. I still update the ports misc/zoneinfo and the timezone data on it. I still use it at home to do my email on, to IRC on and to do things for which I don't have the software on the Mac mini. I made an app for the iPhone called "The FreeBSD Project" which gives some of the social aspects of FreeBSD and the people around it.

Today I've decided to handover some tasks in relation to the things I did for the FreeBSD project. One is the GNATS Auto Assign project for the PRs in relation to the ports system, most likely going into the capable hands of the Bugmeister team. The next one will be a batch of ports, they are up for grab. Except the software I made myself and misc/zoneinfo, something I still manage to keep up to date.

I will see if I can get the FreeBSD Multimedia Resources back into air again, it has grown stale for a good 15 months. Point the finger at me if you need.

Show comment | Share on Facebook | Share on Twitter

Updated iPhone apps

Posted on 2010-08-19 18:10:00
Tags: iPhone, FreeBSD, L-Space

iPhone apps updated:

The FreeBSD Project: iPad compatibility added, fixed Planet FreeBSD links towards the original postings.
L-Space - Discworld: iPad compatibility added. See previous posting on this weblog :-)

No comments | Share on Facebook | Share on Twitter

The FreeBSD Project app

Posted on 2010-06-09 18:00:00
Tags: iPhone, FreeBSD

When exploring the features of the iPhone SDK, one of the things which you can't go around is the "How do I access the Map feature?". Not that I have much to map, I know where I live and that my parents and my/their family lives on the other side of this planet. But there is a different community I still am a member from: That one of the FreeBSD Project!

One of the things that a new committer on the FreeBSD Project does do is to add his name to the astro/xearth port, with the right coordinates so other people know more or less where you live. I feel a map coming up!

But the FreeBSD community is larger than just a map of the committers. There is a Newsflash on the website so you can see what is happening inside the project, there is a list of events related to (Free)BSD on the website, there is of course Planet FreeBSD, an aggregator of the various blogs of people related to the FreeBSD Project and there are videos of conferences on YouTube.

Put all together in a small app which collects all that data and presents it to the person holding the iPhone et voila, the FreeBSD Project app is here.

Show comment | Share on Facebook | Share on Twitter

FreeBSD TFTP server and client updated

Posted on 2010-05-05 08:00:00
Tags: FreeBSD, tftp

Thanks to the bravery (or the despair, I am not sure) of Warner Losh aka imp@, the FreeBSD base system now comes with a much needed upgrade of the TFTP server and client.

Although the code has been available for a two years already as the net/freebsd-tftp port and I used successfully and extensively in my previous job at BarNet, I never maneged (dared?) to commit it into the FreeBSD base system.

The import of the new code was announced as such:

Go ahead and merge the work edwin@ on tftpd into the tree. It is a lot better than what's in the tree now. Edwin tested it at a prior employer, but can't test it today. I've found that it works a lot better with the various uboot versions that I've used in my embedded work.
It all started when we got some new routers, which told me the following when trying to upload configuration or download images from it: The TFTP server doesn't support the blocksize option.
My curiousity was triggered, it took me some reading of RFCs and other documentation to find out what was possible and what could be done. Was plain TFTP very simple in its handshake, TFTP with options was kind of messy because of its backwards capability: The first packet returned could either be an acknowledgement of options, or the first data packet.
Going through the source code of src/libexec/tftpd and going through the code of src/usr.bin/tftp showed that there was a lot of duplicate code, and the addition of options would only increase the amount of duplicate code. After all, both the client and the server can act as a sender and receiver.
At the end, it ended up with a nearly complete rewrite of the tftp client and server. It has been tested against the following TFTP clients and servers:

Itself (yay!)
The standard FreeBSD tftp client and server
The Fedora Core 6 tftp client and server
Cisco router tftp client
Extreme Networks tftp client

It supports the following RFCs:

RFC1350 - THE TFTP PROTOCOL (REVISION 2)
RFC2347 - TFTP Option Extension
RFC2348 - TFTP Blocksize Option
RFC2349 - TFTP Timeout Interval and Transfer Size Options
RFC3617 - Uniform Resource Identifier (URI) Scheme and Applicability Statement for the Trivial File Transfer Protocol (TFTP)

It supports the following unofficial TFTP Options as described at http://www.compuphase.com/tftp.htm:

blksize2 - Block size restricted to powers of 2, excluding protocol headers
rollover - Block counter roll-over (roll back to zero or to one)

From the tftp program point of view the following things are changed:

New commands: "blocksize", "blocksize2", "rollover" and "options"
Development features: "debug" and "packetdrop"

If you try this tftp/tftpd implementation, please let me know if it works (or doesn't work) and against which implementaion so I can get a list of confirmed working systems.

No comments | Share on Facebook | Share on Twitter

tzdata2010b - FreeBSD users in Mexico, heads up!

Posted on 2010-01-27 08:00:00
Tags: zoneinfo, FreeBSD, Mexico, DST

The Mexican government has re-arranged the DST schedule of the northern part of their country to follow the DST schedule of the United States:

Mexico's Congress passed a law in December 2009, bringing the DST schedule observed by northern Mexico's border cities to be in line with the United States' DST schedule. The proposed daylight saving arrangement will affect the following areas:

Tijuana, Mexicali, Ciudad Juarez, Ojinaga, Ciudad Acuna, Piedras Negras, Anahuac, Nuevo Laredo, Reynosa, Matamoros.

The new DST schedule will see these areas move the clocks forward from 2am (02:00) to 3am (03:00) local time on the second Sunday of March, and then back from 2am (02:00) to 1am (01:00) local time on the first Sunday of November. [...]

These changes are available now in FreeBSD 8-STABLE, 7-STABLE, 6-STABLE and HEAD (and the upcoming 7.3 release). For people not following the stable track, please use the port misc/zoneinfo to update.

No comments | Share on Facebook | Share on Twitter

Internode IPv6 over ADSL project

Posted on 2009-11-06 18:00:00
Tags: FreeBSD, IPv6

Internode has announced IPv6 capabilities for their ADSL users and I have volunteered for the pilot. My ADSL router, a Linksys WAG54G2 running version 1.00.17, didn't support it out of the box, so I needed to do it via the FreeBSD host sitting behind it. The FreeBSD host is running 8.0-RC2 at this moment, but it should work with previous versions too:

The first step is to turn the ADSL router into an ADSL modem by changing the Encapsulation on the WAN side from RFC 2516 PPPoE to Bridged Mode Only. From that moment in time you have lost your internet connection :-)

Add to your /etc/rc.conf:

ipv6_enable="YES"

` That was simple. Reboot :-)

Setup PPP on the FreeBSD host, add this to your /etc/ppp/ppp.conf:

pppoe6:
    set authname "edwing@ipv6.internode.on.net"
    set authkey "secret"
    set device PPPoE:sk0
    enable lqr echo
    nat enable yes
    set cd 5
    set dial
    set login
    set redial 0 0
    set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0
    add default HISADDR                 # Add a (sticky) default route
    add default HISADDR6                # Add a (sticky) default route

Notes:

The name for the account has to be changed from @internode.on.net to @ipv6.internode.on.net.
sk0 is the NIC my FreeBSD host is connected via to the ADSL modem.

and start the ppp service:

[~] root@k7>ppp pppoe6
Loading /lib/libalias_cuseeme.so
Loading /lib/libalias_ftp.so
Loading /lib/libalias_irc.so
Loading /lib/libalias_nbt.so
Loading /lib/libalias_pptp.so
Loading /lib/libalias_skinny.so
Loading /lib/libalias_smedia.so
Working in interactive mode
Using interface: tun0
ppp ON k7> dial
ppp ON k7> Warning: deflink: Reducing configured MRU from 1500 to 1492
Ppp ON k7> Warning: deflink: Reducing configured MRU from 1500 to 1492
PPp ON k7> Warning: ::/: Change route failed: errno: No such process
PPp ON k7> 
PPP ON k7>

and the the PPP interface has been setup:

[~] root@k7>ifconfig tun0
tun0: flags=8051 metric 0 mtu 1492
        inet6 fe80::20f:eaff:fe2c:d518%tun0 prefixlen 64 scopeid 0x4 
	inet 150.101.113.58 --> 150.101.197.23 netmask 0xffffff00 
	Opened by PID 35920

And the default gateways have been set:

[~] edwin@k7>netstat -rn | grep default
default            150.101.197.23     UGS         0      340   tun0
default                           fe80::20c:86ff:fe75:241b%tun0 UGS        tun0

Now we have the IPv6 configuration setup, but can't do much except for pinging out default gateway:

[~] edwin@k7>ping6 -c 1 fe80::20c:86ff:fe75:241b
PING6(56=40+8+8 bytes) fe80::20f:eaff:fe2c:d518%tun0 --> fe80::20c:86ff:fe75:241b
16 bytes from fe80::20c:86ff:fe75:241b%tun0, icmp_seq=0 hlim=64 time=10.544 ms

--- fe80::20c:86ff:fe75:241b ping6 statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 10.544/10.544/10.544/0.000 ms
[~] edwin@k7>ping6 -c 1 www.freebsd.org
PING6(56=40+8+8 bytes) fe80::20f:eaff:fe2c:d518%tun0 --> 2001:4f8:fff6::21

--- www.freebsd.org ping6 statistics ---
1 packets transmitted, 0 packets received, 100.0% packet loss

The next step is to grab an allocation of IPv6 addresses for our network: First install the net/dhcp6 port and use the following configuration for /usr/local/etc/dhcp6c.conf:

interface sk0 {
        information-only;
};

interface tun0 {
	send ia-pd 0;
};
id-assoc pd {
	prefix-interface sk0 {
		sla-id 1;
		sla-len 4;
	};
};

Notes:

Interface sk0 is the NIC in the FreeBSD on which the IPv6 subnet should be defined.
Interface tun0 is the interface PPP created.
sla-len 4 is the number of bits the size of the IPv6 subnet you get from Internode: 64 - 4 = 60 bits (See the IPv6 ADSL Trial pages on the Internode website)

The dhcp6c program is not very informative with its output:

[~] root@k7>dhcp6c -f -d  tun0
Nov/06/2009 11:59:35: dhcp6_ctl_authinit: failed to open /usr/local/etc/dhcp6cctlkey: No such file or directory
Nov/06/2009 11:59:35: client6_init: failed initialize control message authentication
Nov/06/2009 11:59:35: client6_init: skip opening control port

But ifconfig sk0 now gives the proper output:

[~] root@k7>ifconfig sk0
sk0: flags=8843 metric 0 mtu 1500
	options=b
	ether 00:0f:ea:2c:d5:18
	inet6 2001:44b8:7bf1:a51:20f:eaff:fe2c:d518 prefixlen 64 
	media: Ethernet autoselect (100baseTX )
	status: active

I don't know why it says there that the prefix-length is 64 bits, but the IPv6 connectivity is there:

[~] root@k7>ping6 -c 1 www.freebsd.org
PING6(56=40+8+8 bytes) 2001:44b8:7bf1:a51:20f:eaff:fe2c:d518 --> 2001:4f8:fff6::21
16 bytes from 2001:4f8:fff6::21, icmp_seq=0 hlim=56 time=194.522 ms

--- www.freebsd.org ping6 statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 194.522/194.522/194.522/0.000 ms

Now you have one FreeBSD computer with IPv6 connectivity. The next step is to enable it on the rest of the network. Add to your /etc/rc.conf:

ipv6_gateway_enable="YES"
rtadvd_enable="YES"
rtadvd_interfaces="sk0"

As seen earlier, sk0 is the ethernet interface of my FreeBSD machine.

To enable IPv6 connectivity on the other computers....

FreeBSD laptop: Add to /etc/rc.conf

ipv6_enable="YES"
rtsol_interfaces="fxp0"
ipv6_default_gateway="fxp0"

and reboot. It now is properly configured too:

[~] edwin@vaio>ifconfig fxp0
fxp0: flags=8843 metric 0 mtu 1500
        options=2009
	ether 00:01:4a:83:a5:82
	inet6 fe80::201:4aff:fe83:a582%fxp0 prefixlen 64 scopeid 0x3 
	inet 10.204.250.107 netmask 0xffffff00 broadcast 10.204.250.255
	inet6 2001:44b8:7bf1:a51:201:4aff:fe83:a582 prefixlen 64 autoconf 
	media: Ethernet autoselect (100baseTX )
	status: active

and

[~] edwin@vaio>ping6 -c 1 www.freebsd.org
PING6(56=40+8+8 bytes) 2001:44b8:7bf1:a51:201:4aff:fe83:a582 --> 2001:4f8:fff6::21
16 bytes from 2001:4f8:fff6::21, icmp_seq=0 hlim=55 time=193.748 ms

--- www.freebsd.org ping6 statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 193.748/193.748/193.748/0.000 ms

On the MacOS/X machine: It came up with IPv6 connectivity after a reboot.

Show comment | Share on Facebook | Share on Twitter

tzsetup(8) changes

Posted on 2009-10-22 09:00:00
Tags: FreeBSD, zoneinfo

In the last couple of days I have scratched a couple of the itches I had with regarding to the timezone database on the FreeBSD Operating System, all related to the (in)ability to update /etc/localtime automatically or quickly:

After running tzsetup(8), it will keep the name of the select zoneinfo file in /var/db/zoneinfo.
You can automatically reinstall the last selected zoneinfo name (after an upgrade with cvsup or the misc/zoneinfo port) via the command tzsetup -r.
Support for installation of installation with the DESTDIR variable set via the -C option.
If you want to change your timezone and you know the zoneinfo name you want to change it to, you can do it quickly via the command tzsetup Australia/Sydney.

This feature is currently only available in FreeBSD -CURRENT, after the release of 8.0 I will merge it back into FreeBSD 8.0 and 7.0.

The port misc/zoneinfo and the installation script of src/share/zoneinfo do support these new features.

No comments | Share on Facebook | Share on Twitter

Localisation in the FreeBSD operating system: share/{monet,msg,numeric,time}def

Posted on 2009-09-08 17:00:00
Tags: FreeBSD, Localisation

(This text was originally posted to the [email protected] mailinglist)

In the last couple of months I've spend some time with the data in the share/{monet,msg,numeric,time}def directories and the data from the CLDR (Common Locale Data Repository) project.

The biggest issues with the way the current data in the *def directories is maintained is that it is partly high-ascii (specially for the non-US-ASCII and non-ISO8859-{1,2,15} character maps) and partly un-synchronized between the different character maps for the same locale.

The first approach was to see if I could transform the data from the CLDR project into the format the FreeBSD project wanted to have it. It taught me a lot about the data stored in the CLDR project, but also that it isn't compatible enough to do it automatic.

The second approach, still happening now, is going much better: Instead of storing the high-ascii and multiple charactermap translations in the SCM, we have per locale one file with a proper definition of the words and syntax used, which gets converted into UTF-8 and which then gets transformed to the required charactermaps.

For example, the file share/msgdef/nl_NL.unicode:

# yesexpr
^[<LATIN SMALL LETTER J><LATIN CAPITAL LETTER J><LATIN SMALL LETTER Y><LATIN CAPITAL LETTER Y>].*
# noexpr
^[<LATIN SMALL LETTER N><LATIN CAPITAL LETTER N>].*
# EOF

gets converted into nl_NL.UTF-8:

# yesexpr
^[jJyY].*
# noexpr
^[nN].*
# EOF

and gets transformed into its ISO8859-1 and ISO8859-15 equivalents. Since this is low-ascii it is a boring example, but the idea is there.

What are currently show-stoppers?

The conversion between .unicode and .UTF-8 is done via a Perl script and the CLDR database, which means that it won't be in the base system for now. So we need both the .unicode source files and the .UTF-8 files in the SCM system.
There is no iconv in the base operating system yet. Gabor@ is in the process of porting citrus-iconv from NetBSD, but it isn't available yet. So we also need the converted charactermaps in the SCM for now. I have access to his iconv and will feed the current issues back to him.

These two show-stoppers right now cause that we will get a lot more data in the SCM system than what we have right now until they are resolved. The first one should not be difficult, the second one is with somebody who understands it :-)

So the advantages, when everything is ready:

Human readable source files with Unicode style encoding.
All locales with the different character maps are generated from one source and thus up-to-date with each other.

Once this part is working properly (and to others people satisfaction) we can update the contents with information from third party sources like the CLDR. But that is still a long time away for now.

No comments | Share on Facebook | Share on Twitter

Huawei E169 on 7-STABLE

Posted on 2009-07-27 20:00:00
Tags: FreeBSD, Huawei E169

Two weeks ago I moved on my laptop from 7.2 BETA2 (SVN revision r191457) from 7-STABLE (SVN revision r195649). Why? Just because I thought I could...

it wasn't the worlds best upgrade I have had. Yes, everything still worked, like X, my network, the ports etc. Except that when using the Huawei E169 3G modem everything hang now and then. Not everything, just the keyboard (network and mouse still worked, so killing X and restarting it was possible if you could access it), but it was enough to have to make the laptop to shut down and to have do an fsck on it. And doing that on the train early in the morning is not my idea of a good time.

I remembered that Peter Jeremy had the same issue earlier after I wrote up the first stories about the E169 and his solution was to upgrade to CURRENT. Yech, that isn't something I want to do on my daily machine. So for two weeks I kind of worked without a network on the train until I finally had enough of it and installed CURRENT on the laptop. And it came up as 8.0 BETA2 (SVN revision 195900).

And I just my first trip on the train with a network again and without having to run fsck during the trip!

No comments | Share on Facebook | Share on Twitter

Huawei E169 statistics

Posted on 2009-06-04 08:00:00
Tags: FreeBSD, Huawei E169, 3G

As written earlier about, the Huawei E169 3G USB modem works like a charm on FreeBSD 7.2. On my trips with the train in the morning to work and in the afternoon from work I am able to do some work on catching up on email and keeping up with the news websites. Yay for a good technology.

The only thing I hadn't managed so far was to getting information from the device to about the amount of traffic uploaded and downloaded, the signal strength and the connection-type used (3G, 2G etc). I knew that the device had three modem ports, one used for the PPP connection but the other two were a mystery so far, until I heard one day that I should use cat(1) instead of tail(1) on them. And yes, that one gave me data!

There are five interesting pieces of text reported:

^BOOT - of which I have no idea what it is for. The values always seem the same, very boring. It is the only field which comes without a change of the data, the others only come when a piece of the data is changed.

^DSFLOWRPT - the most interesting part: It contains the uptime of the PPP connection (always a 2 second interval if there is a modem connection), the number of bytes received and sent out in the last interval, the number of bytes received and sent since the PPP connection got started and two numbers which I don't know what they are for.

^MODE - which tells me if the modem light is cyan, darblue, green or off.

^RSSI - Receiving signal strength, an indication if you are in a tunnel, in a hilly area or close by a basestation.

^SRVST - Not sure yet... It seems to have to be done with which provider you are linked up with and it seems to be toggling between 0 and 4.

So three days later on the train-trip I had mastered ncurses(3x) and created a nice overview of what the 3G modem thinks about my connection:

This screenshot was taken between Kirrawee station and Sutherland station, while checking the contents of the items in the ABC and BBC RSS feeds.

The stats at the top left are just the data as known at this moment. The -1 of the SRVST means we hadn't received that data yet. The table at the top right is the amount of downloaded data during those minute. And the graph at the bottom indicates the signal strength in the last N * 2 seconds.

If you have a Huawei E169 and interested in knowing what is happening, the FreeBSD port is available as net/e169-stats.

Show 6 comments | Share on Facebook | Share on Twitter

FreeBSD - import of tzcode2009e

Posted on 2009-05-24 08:00:00
Tags: FreeBSD

As posted earlier, I have created updates to get the imported timezone code, which is responsible for zdump(8), zic(8) and the stdtime part of libc, from version 2004a to version 2009e (2008e in the earlier post).

The situation became hot again when people found out that Linux applications running linux_base-fc8 and newer gave the wrong time: It expected the new format of the timezone while FreeBSD had the old one.

The only thing you have to take care of is, when you have upgraded your machine, is that you should run at least once tzsetup(8) to make sure the newly created datafiles are installed in /etc/localtime.

I have planned to MFC the changes in one month into the RELENG_7 branch, so everybody should be happy!

No comments | Share on Facebook | Share on Twitter

FreeBSD and the Huawei E169 USB 3G Modem - Step two

Posted on 2009-04-27 21:00:00
Tags: Huawei E169, FreeBSD, Networking, 3G

The story so far... An upgrade to FreeBSD 7.2, X not working, something goes wrong in the IPCP layer, a non-working MacOS/X upgrade and in need of a firmware upgrade.

When I put the E169 in the first Windows machine I found, it kind of died a horrible way: it kept telling me that it had found new hardware and when I was lucky enough, I managed to run it before it decided that it had found new hardware again. Flashing it to a new firmware version was a little bit optimistic for that machine!

Today I took it the E169 modem with me to work and during lunch I put it in a Windows machine there. It installed without an itch, it connected to the Virgin network and it downloaded at a wopping speed of 150 kbps. Now why did it work there and how did it achieve it?

I found a program called Advanced Serial Port Monitor which kind of puts itself between the Windows COM port drive and the Windows kernel and displays what is being said between the client and the hardware.

The client program said "AT+CGMM?" and the modem said "E169". The client program said "AT^CARDLOCK?" and the modem said "^CARDLOCK: 2,10,0" (any idea?). The client program said "AT+CIMI" and the modem said "5050299062636465". And the client program said "AT+COPS?" and the modem said "+COPS: 1,0,"YES OPTUS",2". And a lot of other AT commands were issued, but unfortunately the client program didn't want to dial out while the monitor was running...

Unfortunately, none of the AT commands helped me from getting a proper CONNECT string (CONNECT 7200000 was the one I was looking for) and getting the IPCP part of the PPP initialisation working.

None of this helped. I kept looking and looking and suddenly I saw this one being executed instead of the "YES OPTUS" one: "AT+COPS=1,2,"50502",2". It didn't make much sense, but never tried is always miss. And I ended up with a CONNECT 7200000 and a full PPP handshake session. Bingo!

So, at the end, we ended up with the following configuration on the modem (just in case it differs from yours and it doesn't work):

ati
Manufacturer: huawei
Model: E169
Revision: 11.314.17.00.261
IMEI: 351029385479124
+GCAP: +CGSM,+DS,+ES

at&v
&C: 2; &D: 2; &E: 0; &F: 0; &S: 0; &W: 0; E: 1; L: 0; M: 0; Q: 0; V: 1;
X: 0; Z: 0; \Q: 3; \S: 0; \V: 0; S0: 0; S2: 43; S3: 13; S4: 10; S5: 8;
S6: 2; S7: 50; S8: 2; S9: 6; S10: 14; S11: 95; S30: 0; S103: 1; S104: 1;
+FCLASS: 0; +ICF: 3,3; +IFC: 2,2; +IPR: 115200; +DR: 0; +DS: 0,0,2048,6;
+WS46: 12; +CBST: 0,0,1;
+CRLP: (61,61,48,6,0),(61,61,48,6,1),(240,240,52,6,2);
+CV120: 1,1,1,0,0,0; +CHSN: 0,0,0,0; +CSSN: 0,0; +CREG: 0; +CGREG: 0;
+CFUN:; +CSCS: "IRA"; +CSTA: 129; +CR: 0; +CRC: 0; +CMEE: 2; +CGDCONT: (1,"IP","VirginBroadband","0.0.0.0",0,0)
; +CGDSCONT: ; +CGTFT: ; +CGEQREQ: (1,2,0,0,0,0,2,0,"0E0","0E0",3,0,0),(2,2,0,0,
0,0,2,0,"0E0","0E0",3,0,0),(3,2,0,0,0,0,2,0,"0E0","0E0",3,0,0),(4,2,0,0,0,0,2,0,
"0E0","0E0",3,0,0),(5,2,0,0,0,0,2,0,"0E0","0E0",3,0,0),(6,2,0,0,0,0,2,0,"0E0","0
E0",3,0,0),(7,2,0,0,0,0,2,0,"0E0","0E0",3,0,0),(8,2,0,0,0,0,2,0,"0E0","0E0",3,0,
0),(9,2,0,0,0,0,2,0,"0E0","0E0",3,0,0),(10,2,0,0,0,0,2,0,"0E0","0E0",3,0,0),(11,
2,0,0,0,0,2,0,"0E0","0E0",3,0,0),(12,2,0,0,0,0,2,0,"0E0","0E0",3,0,0),(13,2,0,0,
0,0,2,0,"0E0","0E0",3,0,0),(14,2,0,0,0,0,2,0,"0E0","0E0",3,0,0),(15,2,0,0,0,0,2,
0,"0E0","0E0",3,0,0),(16,2,0,0,0,0,2,0,"0E0","0E0",3,0,0)
; +CGEQMIN: ; +CGQREQ: ; +CGQMIN: ; ; +CGEREP: 0,0; +CGCLASS: "B";
+CGSMS: 1; +CSMS: 0; +CMGF: 0; +CSAS: 0; +CRES: 0;
+CSCA: "+61411990010",145; +CSMP: ,,0,0; +CSDH: 0; +CSCB: 0,"","";
+FDD: 0; +FAR: 0; +FCL: 0; +FIT: 0,0; +ES: ,,; +ESA: 0,,,,0,0,255,;
+CMOD: 0; +CVHU: 1; ; +CPIN:         ,        ; +CMEC: 0,0,0; +CKPD: 1,1;
+CGATT: 1; +CGACT: 0; +CPBS: "SM";  +CPMS: "SM","SM","SM";
+CNMI: 0,0,0,0,0; +CMMS: 2; +FTS: 0; +FRS: 0; +FTH: 3; +FRH: 3; +FTM: 96;
+FRM: 96; +CCUG: 0,0,0; +COPS: 1,0,""; +CUSD: 0; +CAOC: 1; +CCWA: 0;
+CCLK: ""; +CLVL: 4; +CMUT: 0; +CPOL: 0,2,"",0,0,0; +CPLS: 0; +CTZR: 0;
+CTZU: 0; +CLIP: 0; +COLP: 0; +CDIP: 0; +CLIR: 0; ^PORTSEL: 0;
^CPIN:         ,        ; ^ATRECORD: 0; ^FREQLOCK: 12805096,13050984;
^CVOICE: 0; ^DDSETEX: 0

and the following ppp.conf:

virgin:
 set mru 1440
 set device /dev/cuaU0.0
 set speed 115200
 set phone *99\#
 set authname VirginBroadband
 set authkey VirginBroadband
 deny chap

 disable deflate
 disable pred1
 disable vjcomp
 disable mppe

 enable dns
 accept dns

 set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \
           \"\" AT OK-AT-OK ATE1Q0 OK \
	   AT+COPS=1,2,"50502",2 OK \
           AT+CGDCONT=1,\\\"IP\\\",\\\"VirginBroadband\\\" OK \
           \\dATDT\\T TIMEOUT 40 CONNECT"
 set ifaddr 10.0.0.1/0 10.0.0.2/0 0.0.0.0 0.0.0.0

 add default HISADDR

This only brings up the issue with X: Starting X with the E169 modem plugged in did make it start the X graphical screen but it failed to start the window manager and the mouse was unresponsive. Taking out the modem resulted in going back to the console.
Starting X without the E169 modem plugged in started everything up but after plugging in the modem the whole system became unresponsive. Taking out the modem and everything worked again.

I got a hint from Callum on #bugs that I should try x11-servers/xorg-server without hald support. A recompile later and X and the mouse works with the modem plugged in, but the keyboard didn't work yet. Adding these four lines to my xorg.conf overcame the problem:

Section "ServerFlags"
        Option "AllowEmptyInput" "False"
        Option "AutoAddDevices" "False"
EndSection

The xorg-server now works with hald support compiled in, but it doesn't start the window manager yet when hald is running: It just hangs there. Pressing control-alt-backspace and taking the modem out brings you back the console. At this moment it is not really a problem yet, more something for the wizards who understand X.

Short version: The E169 modem works with FreeBSD 7.2 out of the box, Xorg 7.4 works with four extra lines in the config, the XFCE window manager works, everybody is happy!

Show 4 comments | Share on Facebook | Share on Twitter

FreeBSD and the Huawei E169 USB 3G Modem - Step one

Posted on 2009-04-25 19:00:00
Tags: Huawei E169, FreeBSD, Networking, 3G

Earlier this century I had a Huawei E220 USB 3G modem in my possession and believe it or not, after some fiddling and hacking I got it working under FreeBSD 6.x. (Un)fortunately I quit my job and had to give it back.

Overtime it got more and more difficult to find 3G provide who offered a E220 and I had given up on ever running 3G on my FreeBSD laptop again until I saw a commit of Poul-Henning Kamp which said "Make the ubsa(4) work with Huawei Exxx (tested with E169) 3G radio devices".

It took me still quiet a couple of months before I dared to go looking for a replacement and last week I found out that Virgin shop was the only 3G provider who could tell me from their head which brand and model USB modem they provided. And it was a Huawei E169! Life would be sweet again!

Luckily the commit by Poul wasn't too big and I was able to backport it to the 7.1 release running on my laptop and oh boy... It didn't really work yet. For some reason it did the same as my previous modem did before:

$ ppp virgin
ppp> dial
Ppp>
PPp>

It still didn't finish the IPCP layer! I checked the APN, which is VirginBroadband. And I remembered what I did last time: I had to put it in a Windows machien before it worked. I still don't understand this, but okay.

Stopping the PPP program caused a kernel panic. Rebooting the machine without stopping the PPP program caused a kernel panic. Starting X while the USB modem was in caused in a hanging X. Putting the USB modem in while X was running caused a hanging keyboard. Fsck was very upset with me, every time.

So, later I found a commit of Nick Hibma which said "Say hello to the u3g driver, implementing support for 3G modems." plus a bunch of follow-up commits with fixes. And, it was backported into RELENG_7! So I upgraded my laptop to 7.2 (RC1 or something) and rebooted.... It didn't recognize the USB modem at the first attempt, but when I loaded the u3g.ko kernel module it recognized both the modem and the disk part of it! No more patches, it is all vanilla 7.2.

But for some reason it did the same as my previous attempt did before:

$ ppp virgin
ppp> dial
Ppp>
PPp>

That kind of euhm... sucks bigtime.

I don't have a Windows machine, but I do have access a MacOSX machine which should be supported out of the box! The USB modem goes into the MacOSX machine, the software gets installed and I click on the "Connect" button. It says "Connecting" and it comes back with "Connection failed". Euhm...

Looking further, it seems that the program SetNetworkConfig gets called when you press the Connect button and it crashes. At least it gives me some kind of hint where to go next: I need to get newer software, either from Huawei E169 download page or from Virgin Broadband website. The installer of this puts the new software runs on the USB modem and for some reason it only works on a Windows machines.

So tomorrow I'm going to find me a Windows machine, put the USB modem in it, see if it works with Virgin 3G, then see if it then works on my FreeBSD machine, if not then upgrade the software first, see if it still works on the Windows machine and then see if it gets to work on the FreeBSD machine.

Lots of adventures are pending!

Show comment | Share on Facebook | Share on Twitter

iPod A1285 and FreeBSD happiness

Posted on 2008-12-16 19:00:00
Tags: FreeBSD, iPod, Apple

Earlier this year Naomi got her hands on a blue iPod. It is the first time that an iPod thing invaded our life and now that I spend about a good two hours per day on the train, I think it is the right time. Only, what to put on it?

Music! Everywhere I see people with the white earplugs I hear their music, I see them chosing the next track and I wonder "Which music can be so good that you can listen to it every day?". So music is a no-no.

Podcasts! I have several of them and up to now I always managed to listen to them while I was working from home. Right now I don't have the luxery of working from home, or listening to them on the weekend because I spend all my time entertaining the kids. So for the last weeks these things have been piling up:

[~/.penguintv] edwin@k7>du -skh media/
4.2G    media/
[~/.penguintv] edwin@k7>find media/ -type f | wc
     250     250    9917

So, the port audio/gtkpod to the rescue!

Well, except for one thing: The last step, at the the creation of the database on the iPod the program complains: The following has occurred: Couldn't find the iPod firewire ID. And the result is that all the physical files are on it, but that the iPod doesn't index them. Brilliant piece of crap! (The iPod that is)

Google to the rescue. Use Linux they say, run lsusb(8) they say. I didn't but it didn't give me the right string (WTF??!?!??!). Project iPod got stalled until today. Again Google to the rescue. Use Linux they say, run lsusb(8) they say. For FreeBSD they say, there is a tool for this they say, since usbdevs(8) does not provide enough output they say: http://50hz.ws/dev/getserial.c they say.

It didn't do much, but then it's only 152 lines. That it didn't do much was more related to this line:

if(di.udi_vendorNo != 0x05ac) // dunno if udi_productNo changes depending on the ipod model, so vendor check should suffice
	return;

This is because my iPod shows up with vendor ID 0x05ac.

[~] root@k7>usbdevs -v
[...]
Controller /dev/usb4:
addr 1: high speed, self powered, config 1, EHCI root hub(0x0000), Intel(0x0000), rev 1.00
 port 1 powered
 port 2 powered
 port 3 addr 2: high speed, power 500 mA, config 1, iPod(0x1263), Apple Inc.(0x05ac), rev 0.01
 port 4 powered
[...]

A quick patch later and:

[~] root@k7>./getserial /dev/usb4
[4:2] Apple Inc. - iPod
iSerialNumber: 000A27001D1A3886

Add it to the iPod_Control/Device/SysInfo file on your iPod:

[~] root@k7>cat /mnt/ipod/iPod_Control/Device/SysInfo
ModelNumStr: xB249
FirewireGuid: 0x000A27001D1A3886

And gtkpod will work like a charm!

Show comment | Share on Facebook | Share on Twitter

HAMMER File System (not) on FreeBSD

Posted on 2008-10-15 11:30:00, modified on 2008-10-15 14:30:00
Tags: FreeBSD, HammerFS

I was just listening to the talk Matthew Dillon gave at the NYCBSDCon 2008 about the HAMMER File System.

One of the basic requirements of it is that the type ino_t has to be 64 bits. Unfortunately, on FreeBSD this is still 32 bits...

So for everybody who thinks that this is just a extra filesystem layer added to the FreeBSD operating system, it is a little bit more difficult. For example, the commit log for the DragonFlyBSD revision 1.11 was:

Make nlink_t 32bit and ino_t 64bit. Implement the old syscall numbers
for *stat by wrapping the new syscalls and truncation of the values.
Add a hack for boot2 to keep ino_t 32bit, otherwise we would have to
link the 64bit math code in and that would most likely overflow boot2.
Bump libc major to annotate changed ABI and work around a problem with
strip during installworld. strip is dynamically linked and doesn't play
well with the new libc otherwise.

Support for 64bit inode numbers is still incomplete, because the dirent
limited to 32bit. The checks for nlink_t have to be redone too.

Update at 2008-10-15: It seems that people are already doing work on experimenting with a 64 bit ino_t:

<EvilPete> Mavvie: I have patches in perforce (several versions in fact) that bump ino_t to 64 bits.
<EvilPete> Mavvie: nfsv3 has 64 bit inodes.  we have hacks to hash large nfs inode numbers into freebsd's smaller ones
<EvilPete> Mavvie: also, I increased nlink_t and mode_t from 16 to 32 bits.
<EvilPete> //depot/user/peter/ino64 is one of them

Show comment | Share on Facebook | Share on Twitter

src/share/zoneinfo updated to 2008h

Posted on 2008-10-14 16:00:00, modified on 2008-10-14 21:30:00
Tags: FreeBSD, zoneinfo

Still in time for the release of 7.1: src/share/zoneinfo is updated! Syria is still in summertime until 1 November 2008. For people in Argentinia, it is still unclear if you guys will have DST at the 19th of October, so if you have some form of information please tell me about it, with your sources. At this moment it is still assumed that you will have DST.

MFCs towards RELENG_7 and RELENG_6 have been requested, but not yet granted, but of course also available in the ports collection as misc/zoneinfo.

Update on 2008-10-14: MFCd into RELENG_7, RELENG_6 and 6.4.

No comments | Share on Facebook | Share on Twitter

BUGS and FreeBSD Goodies

Posted on 2008-10-13 16:00:00
Tags: FreeBSD, BUGS

With a new job, the most important thing is to start with a new mug. I tried to find a nice one at CafePress, but there weren't really ones which would make me happy. So I made a couple myself :-)

The first batch has the BUGS (BSD Users Group Sydney) logo on it and are available from CafePress - BSD Users Group Sydney. Just mugs, that's all.

The first batch has the FreeBSD logo on it and are available from CafePress - FreeBSD Users Goodies. Mugs and stickers!

I have put a markup of one dollar per 10 dollars in price (and 50 cents for everything less than 10 dollars), which will be donated to the FreeBSD Foundation as described on FreeBSD Foundation Donations.

There are many more items available, for example clothing, but it's way too tricky to define them all in advance. If you want to have something, let me know and I'll add it!

No comments | Share on Facebook | Share on Twitter

src/share/zoneinfo updated to 2008g

Posted on 2008-10-07 12:00:00, modified on 2008-10-14 21:25:00
Tags: FreeBSD, zoneinfo

Just in time for the release of 7.1: src/share/zoneinfo is updated! Changes are only for Brazil, which had clashes with the DST change during the Carnaval weekend.

Of course also available in the ports collection as misc/zoneinfo for people who don't track RELENG_6 or RELENG_7.

Update on 2008-10-14: MFCd into RELENG_6 and 6.4.

No comments | Share on Facebook | Share on Twitter

FreeBSD and contributed code.

Posted on 2008-09-26 09:00:00
Tags: FreeBSD

The FreeBSD Operating System is partly original code and partly contributed code, like the GNU licensed GCC compiler toolchain, the BSD licensed BIND DNS nameserver and the timezone database.

Sometimes people assume maintainership of the contributed code, for example Doug Barton with the BIND DNS nameserver and I-said-the-fool with the timezone database. The only reason I assumed maintainership for it was because there were upcoming changes with regarding to Daylight Saving Time where I live, so there was a good reason to make sure these definitions were up to date. These days both misc/zoneinfo in the ports collection and share/zoneinfo the base system are updated very shortly after a new timezone update has been released.

Sometimes the maintainers or the people who originally imported the code disappear or let the code go stale (for whatever reason). In the last couple of weeks, with lots of free time, I have updated a couple of these contributed modules:

tzcode2004a to tzcode2008e - tzcode is the software which compiles the timezone files and submits functions like strftime(), asctime() and localtime() in libc. The proposal can be found on the -arch mailinglist in the tzcode update to 2008e thread.
file(1) 4.23 to 4.26 - The code of 4.26 works fine on FreeBSD 7.0 and -current, except for two #ifdef's which have been feed back to the author. The maintainer of the module, David O'Brien, has been informed about this and I have requested for co-maintainership but no (positive) response yet.
ISO 639 and ISO 3166 - ISO 639 contains a list of 2 and 3 letter abbrevations for languages, ISO 3166 contains a list of 2 and 3 letter abbrevation for countries. The PRs are conf/127422 and conf/127429.
top(1) from 3.5b12 to 3.8b1 - The patches have been submitted in the PR bin/127633 and I am still going through the PR database to close related PRs and hunt for interesting features, like Added jail filtering support to top(1).

Updating a module isn't a simple let's patch the changes between version A and B, because often the code has been adapted to work with the FreeBSD Operating System or to have specific FreeBSD features, and it might be easier to get diffs from the original code against the FreeBSD version and find ways to merge these changes, or the functionality, into to the newer versions.

To give an example, the patch between the FreeBSD version of top(1) 3.5b12 and 3.8b1 was 13K lines, but the patch between the stock top(1) 3.5b12 and the FreeBSD top(1) 3.5b12 version was only 1500 lines and so was at the end also the patch between the stock top(1) 3.8b1 and the FreeBSD top(1) 3.8b1 version!

No comments | Share on Facebook | Share on Twitter

src/share/zoneinfo updated to 2008f

Posted on 2008-09-16 21:00:00
Tags: FreeBSD, zoneinfo

Just in time for the release of 7.1 and 6.4: src/share/zoneinfo is updated! Changes are for the countries of Mauritius, Morocco, Pakistan, Palestine, Argentina and Brazil.

Of course also available in the ports collection as misc/zoneinfo.

No comments | Share on Facebook | Share on Twitter

Strange PXE Booting

Posted on 2008-09-10 17:00:00, modified on 2008-09-11 12:00:00
Tags: Networking, FreeBSD, PXE, tftp

After being able to use PXE to boot up virtual machines in QEMU, I found an old computer with an old (1998 firmware) fxp ethernet card (Intel EtherExpress PRO/100 Ethernet) I thought "let's boot FreeBSD -current on it!"

That was easier said than done, because for some reason the ethernet card it was requesting a very strange path:

16:48:24.742828 IP 10.204.250.12.2071 > 10.204.250.2.69:  30 RRQ "pxebootM-^?" octet blksize 1456
        0x0000:  4500 003a 0006 0000 1411 9d06 0acc fa0c  E..:............
	0x0010:  0acc fa02 0817 0045 0026 a4f9 0001 7078  .......E.&....px
	0x0020:  6562 6f6f 74ff 006f 6374 6574 0062 6c6b  eboot..octet.blk
	0x0030:  7369 7a65 0031 3435 3600                 size.1456.

Where is that 0xff coming from? And how can I ever create a file like that?

Let's see if the DHCP answer is correct (with net/dhcpdump, also available from my website):

  TIME: 2008-09-11 10:48:23.169
    IP: 10.204.250.2 (00:0f:ea:2c:d5:18) > 255.255.255.255 (ff:ff:ff:ff:ff:ff)
    OP: 2 (BOOTPREPLY)
 HTYPE: 1 (Ethernet)
  HLEN: 6
  HOPS: 0
   XID: b45ceb89
  SECS: 1024
 FLAGS: 7f80
CIADDR: 0.0.0.0
YIADDR: 10.204.250.12
SIADDR: 10.204.250.2
GIADDR: 0.0.0.0
CHADDR: 00:02:b3:5c:eb:89:00:00:00:00:00:00:00:00:00:00
 SNAME: .
 FNAME: pxeboot.
OPTION:  53 (  1) DHCP message type         2 (DHCPOFFER)
OPTION:  54 (  4) Server identifier         10.204.250.2
OPTION:  51 (  4) IP address leasetime      600 (10m)
OPTION:   1 (  4) Subnet mask               255.255.255.0
OPTION:   3 (  4) Routers                   10.204.250.1
OPTION:  60 (  6) Vendor class identifier   Mavvie
OPTION:  67 (  7) Bootfile name             pxeboot

pxeboot, exactly what I expected. The ethernet card wasn't really helpful neither, it just said "TFTP: File not found" without specifying which file it was looking for. Maybe it happened because the option with the Bootfile name is the last one in the packet and it doesn't know how to handle it. Unfortunately this is 1998 firmware and I'm pretty sure that it isn't available from anywhere, let alone be able to update it...

So let's give it the file it wants. The shell I use nor the terminals I use actually make it possible for me to enter the ASCII character 255. So it's Perl to the rescue:

[/tftpboot] root@k7>perl -e 'link("pxeboot", "pxeboot\xff"); '
[/tftpboot] root@k7>ls -al
total 854
drwxr-xr-x   2 nobody  wheel     512 Sep 10 11:05 .
drwxr-xr-x  21 root    wheel     512 Aug  2 07:40 ..
-rw-r--r--   2 root    wheel  260097 Aug 27 21:20 pxeboot
-rw-r--r--   2 root    wheel  260097 Aug 27 21:20 pxeboot?

Oh... That's a hard-link. Oh well, as long as it works.

Did you see the blksize 1456? If you are using the net/freebsd-tftp port, you will send packets with that size instead of 512 bytes:

16:48:24.747635 IP 10.204.250.2.65265 > 10.204.250.12.2071: UDP, length 15
16:48:24.747821 IP 10.204.250.12.2071 > 10.204.250.2.65265: UDP, length 4
16:48:24.747961 IP 10.204.250.2.65265 > 10.204.250.12.2071: UDP, length 1460
16:48:24.748919 IP 10.204.250.12.2071 > 10.204.250.2.65265: UDP, length 4

Show comment | Share on Facebook | Share on Twitter

Network Administration with FreeBSD 7

Posted on 2008-09-03 17:15:00, modified on 2008-09-05 22:15:00
Tags: FreeBSD, Books, Reviews

As described in the "About the Author" chapter the book Network Administration with FreeBSD 7 by Babak Farrokhi and published by Packt Publishing, this is a book made of scattered notes. And that makes the context of this book so good: It are the notes from an experienced administrator who wants to share his secrets with the world. Although I have been using FreeBSD since the 2.2 versions and I am well known with it, his notes show that there is nothing better to learn from than the experience of peers in the same field you are in.

The size of the pages in the book is wider than the O'Reilly books, which makes it possible to leave it open on your desk while you try out the suggestions and commands printed on them. The order of the chapters is System Configuration, Network Configuration and Network Services and it doesn't only describe the commands available in the base operation system, but also the important ports in the third party software ports collection. The commands and examples in the book are consistent and include the command line, /etc/rc.conf and kernel configuration lines everytime where it is necessary.

Because of the fast development and the broad range of features on the FreeBSD operating system, it is hard to know everything others know. That goes for me with regarding to the GEOM chapter for example, which I never had touched before because I always have used hardware based RAID solutions. And it goes for the author, who didn't write about the GUID partition table for large harddisks.

The FreeBSD operating system has often the approach of "use tools and approaches which have been proven over time" and the mindset of system administrators often reflect this: cvsup is one of these things. But luckely the author mentions the portsnap and freebsd-update tools, although he doesn't mention the fact that the last one can be used for minor version and major version upgrades of the base operating system.

The chapter about jails, one of my favourite features of FreeBSD, is very clear and verbose, but it lacks a reference to the sysutils/ezjail port.

Despite being a book for administrators, the Network Configuration part starts with the basic stuff on how network interfaces work and how to configure them. But it quickly moves forward to VLANs and monitoring mode and Fast EtherChannels. The chapter about tunnelling is partly simple and partly tricky: The simple part is the GRE tunnel in two pages and the tricky part is the IPSEC tunnel in 8 pages. The chapter about PPP describes beside the client configuration also the server configuration, something I have never done before.

The chapter about my favourite thing on network equipment, dynamic routing, is a good start to get things up and running but is missing an essential paragraph about what goes over the wire in case of a successful (or unsuccessful) establishing of routing neighbours.

The firewalls chapter is technically fine, but it shows that the author is natively speaking a language in which words like "a", "an" or "the" are not compulsory to write a grammatically correct sentence: Often these words are missing and its confusing. But there is nothing wrong with the context.

The chapters about Internet Servers and Local Network Services are fine to have a complete overview of all aspects of a FreeBSD system, but it doesn't give more than a quickly name them, give an example and tell how to install them. The book should have been done without these two chapters and they could have been in their own book, with more and deeper examples and troubleshooting tips.

My opinion: Great book, worth having and reading. It could use a review of somebody who is a native English speaker to get the lines better rolling now and then, and a technical review of somebody who can make sure that the examples are correct, but for the rest I would say that it belongs next to the other books like Absolutely FreeBSD and The Complete FreeBSD.

Show comment | Share on Facebook | Share on Twitter

FreeBSD mirrors Spring cleanup!

Posted on 2008-09-02 15:00:00
Tags: FreeBSD, Networking

It's September, which means it is Spring in Australia! The semi-cold weather is gone, the birds are shrieking (still) and the trees still have leaves. And what better can you do in Spring than having a Spring Clean?

This years Spring Clean will be about the mirrors of the FreeBSD project. Over the years a huge amount of mirrors have been gathered, and most of are pretty good. Unfortunately, one or two are broken, not up-to-date, out-of-service, have disappeared or can't be found.

Earlier this month, I did the Spring for the Australian mirrors. DNS is now clean, FTP mirrors are all fine again except for ftp4.au.freebsd.org, CVSup now points to a working server, rsync is still not available and the ISO distribution looks fine. It wasn't even Spring yet, imagine that!

Without statistics you don't know anything, so I made a tool which checks for...

The availability and age of the file TIMESTAMP in the FTP mirrors. This file is updated once per hour on the FTP master site.
The availability of the ISO images on the FTP mirrors. These files are only created at release time, but at least it shows where you can find your ISO images!
The availability and age of the file CVSROOT-ports/modules on the CVSup mirrors. This file is updated once per day.
The availability and age of the file TIMESTAMP in the RSync mirrors. This file is updated once per hour on the FTP master site.
The availability of all dates on the FreeBSD.org main website on the WWW mirrors. This is not often updated (couple of times per month), but it is the only way I could find to overcome timestamp issues with locally generated HTML files.
The consitency of the SOA serial numbers in DNS, and to make sure that all CNAMEs are pointing to defined DNS entries.

So, where to find these goodies? At http://www.mavetju.org/unix/freebsd-mirrors/ is the main overview. The score is calculated on the number of (correct) elements found in each test. It is possible to browse through the history of the statistics (as far as collected that is) and to see which items are changed between two dates.

I have applied for a hat to contact the mirror maintainers and ask them to fix the issues, but haven't heard anything yet.

Show comment | Share on Facebook | Share on Twitter

Internode to support IPv6 tunneling (and more)

Posted on 2008-07-21 09:00:00
Tags: IPv6, Australia, FreeBSD

At About Internode and IPv6, Internode announces that their internal network is supporting IPv6, and that they have IPv6 connectivity to the rest of the IPv6 world.

If you want to use their Tunnel Broker service on FreeBSD (i.e. have an IPv6-over-IPv4 tunnel towards their IPv6 gateway), then use the net/freenet6 port. Make sure you are using version 5.1_x.

The required configuration changes in /usr/local/etc/gw6c.conf are:

userid=edwing
passwd=foobar
server=sixgw.internode.on.net
auth_method=any

Besides being a tunnel broker they also support a native IPv6 connection if you have an ethernet- or fibre link with them.

No comments | Share on Facebook | Share on Twitter

When things you wrong, you want useful error messages

Posted on 2008-07-09 09:00:00
Tags: FreeBSD

The time of output like this, after you do a release update:

kldload: Unsupported file type

is over. I, for one, welcome our new warning message overlords:

kldload: /boot/modules/test.ko: Unsupported file type

Will be available in FreeBSD 6.4, 7.1 and higher.

No comments | Share on Facebook | Share on Twitter

Migrating from i386 to amd64 - ldd(1) on 32 bit objects

Posted on 2008-07-04 09:00:00
Tags: FreeBSD

In the last couple of months I have migrated left-over applications on old i386 servers running FreeBSD 4.something to jails on amd64 servers running FreeBSD 6.3. It works fine, it works like a charm, thanks to the 32 bit compatibility and the misc/compat4x port. I could just copy everything in /usr/local/ to the new jail, run ldconfig -32 /usr/local/lib and everything started without problems.

There was only an issue with the ldd(1) command in the base-system:

[/] root@ed-exigent>ldd `which httpd`
ldd: /usr/local/sbin/httpd: can't read program header
ldd: /usr/local/sbin/httpd: not a dynamic executable

The man-page of rtld(1) revealed that it could work:

[/] root@ed-exigent>LD_32_TRACE_LOADED_OBJECTS=1 `which httpd`
libm.so.4 => /lib32//libm.so.4 (0x280c8000)
libaprutil-1.so.2 => /usr/local/lib/libaprutil-1.so.2 (0x280de000)
libexpat.so.6 => /usr/local/lib/libexpat.so.6 (0x280f2000)
libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x28110000)
libapr-1.so.2 => /usr/local/lib/libapr-1.so.2 (0x281fd000)
libcrypt.so.3 => /lib32//libcrypt.so.3 (0x2821d000)
libpthread.so.2 => not found (0x0)
libc.so.6 => /lib32//libc.so.6 (0x28235000)
libpthread.so.2 => /usr/lib32/libpthread.so.2 (0x2830d000)

So ldd(1) had to be educated about the differences in the ELF header for 32 bit and 64 bit ELF objects. Once that was done, no problem at all anymore!

Patches are available at bin/124906, have been commited to HEAD and will be MFCed in a week.

No comments | Share on Facebook | Share on Twitter

CVSROOT-ports/modules re-animated

Posted on 2008-07-03 10:40:00
Tags: FreeBSD, FreeBSD ports

When it comes to the FreeBSD Ports collection, the CVS repository and the GNATS bug tracking system, people not always understand how its can be made easier.

For example: Did you know that the URL http://bugs.freebsd.org/12345 would bring you automatically to the PR with number 12345? And did you know that if you want to checkout the directory /ports/x11-wm/fvwm95, all you have to do it cvs co fvwm95 (For an easy Mozilla Firefox and Seamonkey (and probably other browsers) sidebar, visit this page)

So, what is the story about that cvs co fvwm95. The magic for that is stored in the file CVSROOT-ports/modules, it contains a list of all ports and their directories. The file is updated every time a port gets commited, removed or changed from location. At least that is the theory. Adding is done manually via the addport script, but removing and changing locations has been always a manual task.

Recently the caretaker of this file had enough of people whinching when he said they needed to update that file when it changed. So he said that support for it would cease. But but but... That would break at least one of my ways to do things easy!

I can do only one thing now, take control over it myself! So I proposed it to portmgr@, who approved it. The second thing to make is a script which mangles /usr/ports/INDEX to generate a modules file (in the shape I like it).

All that is done now, and the CVSROOT-ports/modules file is now updated once per day. See the CVS webinterface for the last update!

No comments | Share on Facebook | Share on Twitter

Using the Internode SourceForge mirror

Posted on 2008-06-03 19:00:00
Tags: FreeBSD, FreeBSD ports

Since a couple of weeks Internode has a Sourceforge mirror, which traffic is free of charge for Internode customers.

If you want to prefer it in your ports configuration, add this to /etc/make.conf:

MASTER_SITE_SOURCEFORGE= \
        http://internode.dl.sourceforge.net/sourceforge/%SUBDIR%/
MASTER_SORT?=   internode.dl.sourceforge.net mirror.internode.on.net .au

No comments | Share on Facebook | Share on Twitter

FreeBSD IPv6 Divert socket adventures (3)

Posted on 2008-05-13 23:00:00
Tags: IPv6, FreeBSD, Networking

Victory! Tonight I managed to get the nat6to4 daemon working. Remember what went wrong yesterday:

IPv6 packet does not go from the nat6to4 daemon into divert. What?!?!?

Yes, that would have worked in one go if I actually had pushed the data in the right IPv6 socket instead of in the wrong IPv4 socket. It happens, specially when you are copying whole functions around.

As a demo:

[~] edwin@freefall>telnet 2001:5c0:8fff:ffff::c3 80
Trying 2001:5c0:8fff:ffff::c3...
Connected to 2001:5c0:8fff:ffff::c3.
Escape character is '^]'.
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Date: Tue, 13 May 2008 14:10:23 GMT
Expires: Thu, 26 Oct 1995 00:00:00 GMT
Last-Modified: Tue, 13 May 2008 14:10:23 GMT
Pragma: no-cache
Content-Length: 32
Server: Allegro-Software-RomPager/4.34

Connection closed by foreign host.

That is pretty uninteresting for the naked eye, but the thing is that the Allegro-Software-RomPager doesn't support IPv6, it's mapped via the nat6to4 gateway.

So, my nat6to4 daemon works for mapping the TCP or UDP payload of basic IPv6 packets (single header, nothing fancy) onto IPv4 packets: Now I can make all basic services on my jails (webservers, LDAP servers, DNS servers, POP and IMAP servers) available via IPv6.

Now I have to put netinet6/ip6_divert.c into a shape so that it gets accepted by the FreeBSD project, right now there are too many things commented out because I didn't know what they are for. Yes, I feel like an apprentice magician left alone with a hand full of scrolls and asked to find out if they are interesting.

Patches for FreeBSD 6.3 are available from http://people.freebsd.org/~edwin/freebsd63-ip6divert-20080513.patch.
The nat6to4d is available from http://people.freebsd.org/~edwin/nat6to4d-20080513.c.
And the ipfw rules:

01005   606   245695 divert 8664 ip from any to 192.168.253.2
01006   452    33304 allow ipv6-icmp from any to me6 via tun1
01006   517    51742 divert 8666 ip6 from any to me6 via tun1
65535 79349 20349420 allow ip from any to any

Show 2 comments | Share on Facebook | Share on Twitter

FreeBSD IPv6 Divert socket adventures (2)

Posted on 2008-05-12 10:00:00
Tags: IPv6, FreeBSD, Networking

A small update:

Dr. Goto has replied. It seems that I contacted him at the beginning on the Golden Week, a week in Japan with a lot of free days so that was the reason it took longer. His patches are against 5.2.1 and applied without problems but didn't compile. But it gave me some good hints.
Three kernel panics later I was told by Bruce M Simpson to use Qemu for kernel development work. Two days later I have it up and running. Works nice, I have it booting via PXE and the disks are mounted via NFS. I can boot in several FreeBSD versions but not into 5.2.1 because it hangs just before starting the userland. So far for my reference platform...
I have copied sys/src/netinet/ip_divert.c to sys/src/netinet/ip6_divert.c and modified all IPv4 functions into their IPv6 equivalents. Also added IP_PROTO_SPACERS to in6_proto.h. And finally when I open a socket with PF_INET6 and SOCK_RAW and IPPROTO_DIVERT, I get a proper socket:
```
nat6to4d 2578  root    3u  IPv6    0xc1df8ec4        0t0  DIVERT *:8666
nat6to4d 2578  root    4u  IPv4    0xc1dfaec4        0t0  DIVERT *:8664
```
sockstat still doesn't show it though...

Internally in ip6_divert.c, instead of abusing the sin_zero[] fields in struct sockaddr_in I have created the new sockaddr type struct sockaddr_div:

struct sockaddr_div {
	uint8_t         div_len;
	sa_family_t     div_family;     /* AF_INET / AF_INET6 */
	in_port_t       div_cookie;     /* was: sin_port */
	char            div_iface[8];
	struct in6_addr div6_addr;      /* IPv6 address */
	struct in_addr  div4_addr;      /* IPv4 address */
};

This could / should be also used in the normal ip_divert code.

So what works and what doesn't?

IPv6 packet goes from divert to the nat6to4 daemon. Yay!
(TCP SYN packet from IPv6 host to the IPv6 address of the machine with the nat6to4 daemon)
IPv4 packet goes from the nat6to4 daemon to divert. Yay!
(TCP SYN packet from the IPv4 address of the machine with the nat6to4 daemon to the IPv4 host. Trivia: Why do you need to recalculate the TCP checksum when you haven't changed the TCP header and TCP payload?)
IPv4 packet goes from divert to the nat6to4 daemon. Yay!
(TCP SYN-ACK packet from IPv4 host to the IPv4 address of the machine with the nat6to4 daemon)
IPv6 packet does not go from the nat6to4 daemon into divert. What?!?!?

I'm not sure what goes wrong here: sendto() says that it is accepted, but the packet is expected to end up on the div6_send() function but it doesn't end up there. For some reason. Which is kind of annoying. Robert Watson suggested to check the GDB debugger what happens in the sendto() call.

But that is an adventure for later when I have some spare time again... work and two kids, that doesn't leave much time adventures like this (except between 22:00 and 01:00 which is very bad for everybody)

No comments | Share on Facebook | Share on Twitter

FreeBSD IPv6 Divert socket adventures

Posted on 2008-05-06 10:00:00
Tags: IPv6, FreeBSD, Networking

This whole IPv6 Divert idea seems to be a little bit optimistic now. As all new technology (I wouldn't call IPv6 new technology, but still) not everything you have available now is supported in it.

So, how far did we get?

FreeBSD's ipfw2 supports diverting of IPv6 packets. Yay!
A simple program which listens on the divert socket (IPPROTO_DIVERT) for IPv4 (PF_INET) and prints some information about the packets received works. Yay!
That same program for IPv6 (PF_INET6) doesn't work, lsof says that it is listening for protocol 0 (the catch all) instead of protocol IPPROTO_DIVERT.
Looking through ip_divert() in src/netinet/ip_divert.c shows about the registration of protocols (thanks to bms@ for hints): pf_proto_register(PF_INET, &div_protosw), but when I do this for PF_INET6 it returns an error which is related to the absence of a free IPPROTO_SPACER. And these are (thanks to rwatson@ for hints) not available for IPv6.

So, this is getting trickier and trickier for an userland guy like me to experiment with on a sunday afternoon... But I'm not going to give up! (yet)

On the other hand, an interesting paper by Dr. Goto (I'm not kidding) and friends available at IPV4/V6 NETWORK EMULATOR USING DIVERT SOCKET says:

[...]
We have ported divert socket to IPv6 by adding about 1000
lines of C program code either on FreeBSD and Linux kernel
for this research.
[...]

I have asked him if he wanted to share his code but haven't heard anything back from him.

No comments | Share on Facebook | Share on Twitter

Three Mobile roaming 3G network

Posted on 2008-05-01 08:00:00, modified on 2008-07-14 16:00:00
Tags: Networking, FreeBSD, 3G

Thanks to my job, or cursed by my job sometimes, I have access to a 3G modem of Three Mobile. It works fine in areas where there is Three Mobile coverage, outside these areas were we are roaming (and probably on the Telstra 3G network) there are interesting issues with the IPCP phase (IP Confirguration Protocol) of PPP which make the PPP setup fail.

So what works and what doesn't? According to the PPP manual, this is what we should see:

ppp ON awfulhak>    # No link has been established
Ppp ON awfulhak>    # We've connected & finished LCP
PPp ON awfulhak>    # We've authenticated
PPP ON awfulhak>    # We've agreed IP numbers

The first two Ps become capitals, but the third one doesn't when we are roaming.

What do the logs say? The short version of a successful handshake is:

IPCP: FSM: Using "deflink" as a transport
IPCP: deflink: State change Initial --> Closed
IPCP: deflink: LayerStart.
IPCP: deflink: SendConfigReq(1) state = Closed
IPCP: deflink: State change Closed --> Req-Sent
IPCP: deflink: RecvConfigNak(1) state = Req-Sent
IPCP: deflink: SendConfigReq(2) state = Req-Sent
IPCP: deflink: RecvConfigNak(2) state = Req-Sent
IPCP: deflink: SendConfigReq(3) state = Req-Sent
IPCP: deflink: RecvConfigReq(0) state = Req-Sent
IPCP: deflink: SendConfigNak(0) state = Req-Sent
IPCP: deflink: RecvConfigRej(3) state = Req-Sent
IPCP: deflink: SendConfigReq(4) state = Req-Sent
IPCP: deflink: RecvConfigReq(1) state = Req-Sent
IPCP: deflink: SendConfigAck(1) state = Req-Sent
IPCP: deflink: State change Req-Sent --> Ack-Sent
IPCP: deflink: RecvConfigNak(4) state = Ack-Sent
IPCP: deflink: SendConfigReq(5) state = Ack-Sent
IPCP: deflink: RecvConfigAck(5) state = Ack-Sent
IPCP: deflink: State change Ack-Sent --> Opened

The full log is at the end of this writeup.
The discussion goes like this: I propose something three times (SendConfigReq) and they reject it (RecvConfigNak), but at the third time they say "Let's try it with this" (RecvConfigReq) and we come up with a common ground. And everybody is happy!

The short version of an unsuccessful handshake is:

IPCP: FSM: Using "deflink" as a transport
IPCP: deflink: State change Initial --> Closed
IPCP: deflink: LayerStart.
IPCP: deflink: SendConfigReq(1) state = Closed
IPCP: deflink: State change Closed --> Req-Sent
IPCP: deflink: RecvConfigNak(1) state = Req-Sent
IPCP: deflink: SendConfigReq(2) state = Req-Sent
IPCP: deflink: RecvConfigNak(2) state = Req-Sent
IPCP: deflink: SendConfigReq(3) state = Req-Sent
IPCP: deflink: RecvConfigNak(3) state = Req-Sent
IPCP: deflink: SendConfigReq(4) state = Req-Sent
IPCP: deflink: RecvConfigNak(4) state = Req-Sent
IPCP: deflink: SendConfigReq(5) state = Req-Sent
IPCP: deflink: RecvConfigNak(5) state = Req-Sent
IPCP: deflink: SendConfigReq(6) state = Req-Sent
IPCP: deflink: RecvConfigNak(6) state = Req-Sent
IPCP: deflink: SendConfigReq(7) state = Req-Sent
IPCP: deflink: RecvConfigNak(7) state = Req-Sent
IPCP: deflink: SendConfigReq(8) state = Req-Sent
IPCP: deflink: RecvConfigNak(8) state = Req-Sent
IPCP: deflink: SendConfigReq(9) state = Req-Sent
IPCP: deflink: RecvConfigNak(9) state = Req-Sent
IPCP: deflink: SendConfigReq(10) state = Req-Sent
IPCP: deflink: RecvConfigNak(10) state = Req-Sent
IPCP: deflink: SendConfigReq(11) state = Req-Sent
IPCP: deflink: SendTerminateReq(11) state = Req-Sent
IPCP: deflink: State change Req-Sent --> Closing
IPCP: deflink: RecvTerminateAck(11) state = Closing
IPCP: deflink: LayerFinish.
IPCP: deflink: State change Closing --> Closed
IPCP: deflink: RecvConfigNak(11), dropped (expected 12)

The full log is at the end of this writeup.
Here there are only SendConfigReq and RecvConfigNak, there is no RecvConfigReq coming from them!

If anybody has managed to setup a successful PPP connection on the 3G network of anybody but Three Mobile can send me some logs, I would be very happy to see if I can fix things.

Update According to John Marshall, sending a string similar to this:

AT+CGDCONT=1,"IP","telstra.internet"

could resolve the issue. Next time when I'm in the roaming-zone I'll try it!

It worked, when I used "3netaccess" as the indentifier.

Here are the full logs:

This is the IPCP part of a successful handshake

ppp[1098]: tun0: Phase: bundle: Network
ppp[1098]: tun0: IPCP: FSM: Using "deflink" as a transport
ppp[1098]: tun0: IPCP: deflink: State change Initial --> Closed
ppp[1098]: tun0: IPCP: deflink: LayerStart.
ppp[1098]: tun0: IPCP: deflink: SendConfigReq(1) state = Closed
ppp[1098]: tun0: IPCP:  IPADDR[6] 0.0.0.0
ppp[1098]: tun0: IPCP:  COMPPROTO[6] 16 VJ slots without slot compression
ppp[1098]: tun0: IPCP:  PRIDNS[6] 202.124.76.66
ppp[1098]: tun0: IPCP:  SECDNS[6] 255.255.255.255
ppp[1098]: tun0: IPCP: deflink: State change Closed --> Req-Sent
ppp[1098]: tun0: LCP: deflink: RecvProtocolRej(2) state = Opened
ppp[1098]: tun0: LCP: deflink: -- Protocol 0x80fd (Compression Control Protocol) was rejected!
ppp[1098]: tun0: CCP: deflink: State change Req-Sent --> Stopped
ppp[1098]: tun0: IPCP: deflink: RecvConfigNak(1) state = Req-Sent
ppp[1098]: tun0: IPCP:  PRIDNS[6] 10.11.12.13
ppp[1098]: tun0: IPCP:  SECDNS[6] 10.11.12.14
ppp[1098]: tun0: IPCP:  PRINBNS[6] 10.11.12.13
ppp[1098]: tun0: IPCP: MS NBNS req 130 - NAK??
ppp[1098]: tun0: IPCP:  SECNBNS[6] 10.11.12.14
ppp[1098]: tun0: IPCP: MS NBNS req 132 - NAK??
ppp[1098]: tun0: IPCP: Primary nameserver set to 10.11.12.13
ppp[1098]: tun0: IPCP: Secondary nameserver set to 10.11.12.14
ppp[1098]: tun0: IPCP: deflink: SendConfigReq(2) state = Req-Sent
ppp[1098]: tun0: IPCP:  IPADDR[6] 0.0.0.0
ppp[1098]: tun0: IPCP:  COMPPROTO[6] 16 VJ slots without slot compression
ppp[1098]: tun0: IPCP:  PRIDNS[6] 10.11.12.13
ppp[1098]: tun0: IPCP:  SECDNS[6] 10.11.12.14
ppp[1098]: tun0: IPCP: deflink: RecvConfigNak(2) state = Req-Sent
ppp[1098]: tun0: IPCP:  PRIDNS[6] 10.11.12.13
ppp[1098]: tun0: IPCP:  SECDNS[6] 10.11.12.14
ppp[1098]: tun0: IPCP:  PRINBNS[6] 10.11.12.13
ppp[1098]: tun0: IPCP: MS NBNS req 130 - NAK??
ppp[1098]: tun0: IPCP:  SECNBNS[6] 10.11.12.14
ppp[1098]: tun0: IPCP: MS NBNS req 132 - NAK??
ppp[1098]: tun0: IPCP: Primary nameserver set to 10.11.12.13
ppp[1098]: tun0: IPCP: Secondary nameserver set to 10.11.12.14
ppp[1098]: tun0: IPCP: deflink: SendConfigReq(3) state = Req-Sent
ppp[1098]: tun0: IPCP:  IPADDR[6] 0.0.0.0
ppp[1098]: tun0: IPCP:  COMPPROTO[6] 16 VJ slots without slot compression
ppp[1098]: tun0: IPCP:  PRIDNS[6] 10.11.12.13
ppp[1098]: tun0: IPCP:  SECDNS[6] 10.11.12.14
ppp[1098]: tun0: IPCP: deflink: RecvConfigReq(0) state = Req-Sent
ppp[1098]: tun0: IPCP:   [EMPTY]
ppp[1098]: tun0: IPCP: deflink: SendConfigNak(0) state = Req-Sent
ppp[1098]: tun0: IPCP:  IPADDR[6] 10.0.0.2
ppp[1098]: tun0: IPCP: deflink: RecvConfigRej(3) state = Req-Sent
ppp[1098]: tun0: IPCP:  COMPPROTO[6] 16 VJ slots without slot compression
ppp[1098]: tun0: IPCP: deflink: SendConfigReq(4) state = Req-Sent
ppp[1098]: tun0: IPCP:  IPADDR[6] 0.0.0.0
ppp[1098]: tun0: IPCP:  PRIDNS[6] 10.11.12.13
ppp[1098]: tun0: IPCP:  SECDNS[6] 10.11.12.14
ppp[1098]: tun0: IPCP: deflink: RecvConfigReq(1) state = Req-Sent
ppp[1098]: tun0: IPCP:   [EMPTY]
ppp[1098]: tun0: IPCP: deflink: SendConfigAck(1) state = Req-Sent
ppp[1098]: tun0: IPCP:   [EMPTY]
ppp[1098]: tun0: IPCP: deflink: State change Req-Sent --> Ack-Sent
ppp[1098]: tun0: IPCP: deflink: RecvConfigNak(4) state = Ack-Sent
ppp[1098]: tun0: IPCP:  IPADDR[6] 119.11.8.120
ppp[1098]: tun0: IPCP:  IPADDR[6] changing address: 0.0.0.0  --> 119.11.8.120
ppp[1098]: tun0: IPCP:  PRIDNS[6] 202.124.68.130
ppp[1098]: tun0: IPCP:  SECDNS[6] 202.124.76.66
ppp[1098]: tun0: IPCP: Primary nameserver set to 202.124.68.130
ppp[1098]: tun0: IPCP: Secondary nameserver set to 202.124.76.66
ppp[1098]: tun0: IPCP: deflink: SendConfigReq(5) state = Ack-Sent
ppp[1098]: tun0: IPCP:  IPADDR[6] 119.11.8.120
ppp[1098]: tun0: IPCP:  PRIDNS[6] 202.124.68.130
ppp[1098]: tun0: IPCP:  SECDNS[6] 202.124.76.66
ppp[1098]: tun0: IPCP: deflink: RecvConfigAck(5) state = Ack-Sent
ppp[1098]: tun0: IPCP:  IPADDR[6] 119.11.8.120
ppp[1098]: tun0: IPCP:  PRIDNS[6] 202.124.68.130
ppp[1098]: tun0: IPCP:  SECDNS[6] 202.124.76.66
ppp[1098]: tun0: IPCP: deflink: State change Ack-Sent --> Opened
ppp[1098]: tun0: IPCP: deflink: LayerUp.

This is the IPCP part of a unsuccessful handshake

ppp[1661]: tun0: Phase: bundle: Network
ppp[1661]: tun0: IPCP: FSM: Using "deflink" as a transport
ppp[1661]: tun0: IPCP: deflink: State change Initial --> Closed
ppp[1661]: tun0: IPCP: deflink: LayerStart.
ppp[1661]: tun0: IPCP: deflink: SendConfigReq(1) state = Closed
ppp[1661]: tun0: IPCP:  IPADDR[6] 0.0.0.0
ppp[1661]: tun0: IPCP:  COMPPROTO[6] 16 VJ slots with slot compression
ppp[1661]: tun0: IPCP:  PRIDNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP:  SECDNS[6] 10.11.12.14
ppp[1661]: tun0: IPCP: deflink: State change Closed --> Req-Sent
ppp[1661]: tun0: LCP: deflink: RecvProtocolRej(2) state = Opened
ppp[1661]: tun0: LCP: deflink: -- Protocol 0x80fd (Compression Control Protocol) was rejected!
ppp[1661]: tun0: CCP: deflink: State change Req-Sent --> Stopped
ppp[1661]: tun0: IPCP: deflink: RecvConfigNak(1) state = Req-Sent
ppp[1661]: tun0: IPCP:  PRIDNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP:  SECDNS[6] 10.11.12.14
ppp[1661]: tun0: IPCP:  PRINBNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP: MS NBNS req 130 - NAK??
ppp[1661]: tun0: IPCP:  SECNBNS[6] 10.11.12.14
ppp[1661]: tun0: IPCP: MS NBNS req 132 - NAK??
ppp[1661]: tun0: IPCP: Primary nameserver set to 10.11.12.13
ppp[1661]: tun0: IPCP: Secondary nameserver set to 10.11.12.14
ppp[1661]: tun0: IPCP: deflink: SendConfigReq(2) state = Req-Sent
ppp[1661]: tun0: IPCP:  IPADDR[6] 0.0.0.0
ppp[1661]: tun0: IPCP:  COMPPROTO[6] 16 VJ slots with slot compression
ppp[1661]: tun0: IPCP:  PRIDNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP:  SECDNS[6] 10.11.12.14
ppp[1661]: tun0: IPCP: deflink: RecvConfigNak(2) state = Req-Sent
ppp[1661]: tun0: IPCP:  PRIDNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP:  SECDNS[6] 10.11.12.14
ppp[1661]: tun0: IPCP:  PRINBNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP: MS NBNS req 130 - NAK??
ppp[1661]: tun0: IPCP:  SECNBNS[6] 10.11.12.14
ppp[1661]: tun0: IPCP: MS NBNS req 132 - NAK??
ppp[1661]: tun0: IPCP: Primary nameserver set to 10.11.12.13
ppp[1661]: tun0: IPCP: Secondary nameserver set to 10.11.12.14
ppp[1661]: tun0: IPCP: deflink: SendConfigReq(3) state = Req-Sent
ppp[1661]: tun0: IPCP:  IPADDR[6] 0.0.0.0
ppp[1661]: tun0: IPCP:  COMPPROTO[6] 16 VJ slots with slot compression
ppp[1661]: tun0: IPCP:  PRIDNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP:  SECDNS[6] 10.11.12.14
ppp[1661]: tun0: IPCP: deflink: RecvConfigNak(3) state = Req-Sent
ppp[1661]: tun0: IPCP:  PRIDNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP:  SECDNS[6] 10.11.12.14
ppp[1661]: tun0: IPCP:  PRINBNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP: MS NBNS req 130 - NAK??
ppp[1661]: tun0: IPCP:  SECNBNS[6] 10.11.12.14
ppp[1661]: tun0: IPCP: MS NBNS req 132 - NAK??
ppp[1661]: tun0: IPCP: Primary nameserver set to 10.11.12.13
ppp[1661]: tun0: IPCP: Secondary nameserver set to 10.11.12.14
ppp[1661]: tun0: IPCP: deflink: SendConfigReq(4) state = Req-Sent
ppp[1661]: tun0: IPCP:  IPADDR[6] 0.0.0.0
ppp[1661]: tun0: IPCP:  COMPPROTO[6] 16 VJ slots with slot compression
ppp[1661]: tun0: IPCP:  PRIDNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP:  SECDNS[6] 10.11.12.14
ppp[1661]: tun0: IPCP: deflink: RecvConfigNak(4) state = Req-Sent
ppp[1661]: tun0: IPCP:  PRIDNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP:  SECDNS[6] 10.11.12.14
ppp[1661]: tun0: IPCP:  PRINBNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP: MS NBNS req 130 - NAK??
ppp[1661]: tun0: IPCP:  SECNBNS[6] 10.11.12.14
ppp[1661]: tun0: IPCP: MS NBNS req 132 - NAK??
ppp[1661]: tun0: IPCP: Primary nameserver set to 10.11.12.13
ppp[1661]: tun0: IPCP: Secondary nameserver set to 10.11.12.14
ppp[1661]: tun0: IPCP: deflink: SendConfigReq(5) state = Req-Sent
ppp[1661]: tun0: IPCP:  IPADDR[6] 0.0.0.0
ppp[1661]: tun0: IPCP:  COMPPROTO[6] 16 VJ slots with slot compression
ppp[1661]: tun0: IPCP:  PRIDNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP:  SECDNS[6] 10.11.12.14
ppp[1661]: tun0: IPCP: deflink: RecvConfigNak(5) state = Req-Sent
ppp[1661]: tun0: IPCP:  PRIDNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP:  SECDNS[6] 10.11.12.14
ppp[1661]: tun0: IPCP:  PRINBNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP: MS NBNS req 130 - NAK??
ppp[1661]: tun0: IPCP:  SECNBNS[6] 10.11.12.14
ppp[1661]: tun0: IPCP: MS NBNS req 132 - NAK??
ppp[1661]: tun0: IPCP: Primary nameserver set to 10.11.12.13
ppp[1661]: tun0: IPCP: Secondary nameserver set to 10.11.12.14
ppp[1661]: tun0: IPCP: deflink: SendConfigReq(6) state = Req-Sent
ppp[1661]: tun0: IPCP:  IPADDR[6] 0.0.0.0
ppp[1661]: tun0: IPCP:  COMPPROTO[6] 16 VJ slots with slot compression
ppp[1661]: tun0: IPCP:  PRIDNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP:  SECDNS[6] 10.11.12.14
ppp[1661]: tun0: IPCP: deflink: RecvConfigNak(6) state = Req-Sent
ppp[1661]: tun0: IPCP:  PRIDNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP:  SECDNS[6] 10.11.12.14
ppp[1661]: tun0: IPCP:  PRINBNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP: MS NBNS req 130 - NAK??
ppp[1661]: tun0: IPCP:  SECNBNS[6] 10.11.12.14
ppp[1661]: tun0: IPCP: MS NBNS req 132 - NAK??
ppp[1661]: tun0: IPCP: Primary nameserver set to 10.11.12.13
ppp[1661]: tun0: IPCP: Secondary nameserver set to 10.11.12.14
ppp[1661]: tun0: IPCP: deflink: SendConfigReq(7) state = Req-Sent
ppp[1661]: tun0: IPCP:  IPADDR[6] 0.0.0.0
ppp[1661]: tun0: IPCP:  COMPPROTO[6] 16 VJ slots with slot compression
ppp[1661]: tun0: IPCP:  PRIDNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP:  SECDNS[6] 10.11.12.14
ppp[1661]: tun0: IPCP: deflink: RecvConfigNak(7) state = Req-Sent
ppp[1661]: tun0: IPCP:  PRIDNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP:  SECDNS[6] 10.11.12.14
ppp[1661]: tun0: IPCP:  PRINBNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP: MS NBNS req 130 - NAK??
ppp[1661]: tun0: IPCP:  SECNBNS[6] 10.11.12.14
ppp[1661]: tun0: IPCP: MS NBNS req 132 - NAK??
ppp[1661]: tun0: IPCP: Primary nameserver set to 10.11.12.13
ppp[1661]: tun0: IPCP: Secondary nameserver set to 10.11.12.14
ppp[1661]: tun0: IPCP: deflink: SendConfigReq(8) state = Req-Sent
ppp[1661]: tun0: IPCP:  IPADDR[6] 0.0.0.0
ppp[1661]: tun0: IPCP:  COMPPROTO[6] 16 VJ slots with slot compression
ppp[1661]: tun0: IPCP:  PRIDNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP:  SECDNS[6] 10.11.12.14
ppp[1661]: tun0: IPCP: deflink: RecvConfigNak(8) state = Req-Sent
ppp[1661]: tun0: IPCP:  PRIDNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP:  SECDNS[6] 10.11.12.14
ppp[1661]: tun0: IPCP:  PRINBNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP: MS NBNS req 130 - NAK??
ppp[1661]: tun0: IPCP:  SECNBNS[6] 10.11.12.14
ppp[1661]: tun0: IPCP: MS NBNS req 132 - NAK??
ppp[1661]: tun0: IPCP: Primary nameserver set to 10.11.12.13
ppp[1661]: tun0: IPCP: Secondary nameserver set to 10.11.12.14
ppp[1661]: tun0: IPCP: deflink: SendConfigReq(9) state = Req-Sent
ppp[1661]: tun0: IPCP:  IPADDR[6] 0.0.0.0
ppp[1661]: tun0: IPCP:  COMPPROTO[6] 16 VJ slots with slot compression
ppp[1661]: tun0: IPCP:  PRIDNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP:  SECDNS[6] 10.11.12.14
ppp[1661]: tun0: IPCP: deflink: RecvConfigNak(9) state = Req-Sent
ppp[1661]: tun0: IPCP:  PRIDNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP:  SECDNS[6] 10.11.12.14
ppp[1661]: tun0: IPCP:  PRINBNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP: MS NBNS req 130 - NAK??
ppp[1661]: tun0: IPCP:  SECNBNS[6] 10.11.12.14
ppp[1661]: tun0: IPCP: MS NBNS req 132 - NAK??
ppp[1661]: tun0: IPCP: Primary nameserver set to 10.11.12.13
ppp[1661]: tun0: IPCP: Secondary nameserver set to 10.11.12.14
ppp[1661]: tun0: IPCP: deflink: SendConfigReq(10) state = Req-Sent
ppp[1661]: tun0: IPCP:  IPADDR[6] 0.0.0.0
ppp[1661]: tun0: IPCP:  COMPPROTO[6] 16 VJ slots with slot compression
ppp[1661]: tun0: IPCP:  PRIDNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP:  SECDNS[6] 10.11.12.14
ppp[1661]: tun0: IPCP: deflink: RecvConfigNak(10) state = Req-Sent
ppp[1661]: tun0: IPCP:  PRIDNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP:  SECDNS[6] 10.11.12.14
ppp[1661]: tun0: IPCP:  PRINBNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP: MS NBNS req 130 - NAK??
ppp[1661]: tun0: IPCP:  SECNBNS[6] 10.11.12.14
ppp[1661]: tun0: IPCP: MS NBNS req 132 - NAK??
ppp[1661]: tun0: IPCP: Primary nameserver set to 10.11.12.13
ppp[1661]: tun0: IPCP: Secondary nameserver set to 10.11.12.14
ppp[1661]: tun0: IPCP: deflink: SendConfigReq(11) state = Req-Sent
ppp[1661]: tun0: IPCP:  IPADDR[6] 0.0.0.0
ppp[1661]: tun0: IPCP:  COMPPROTO[6] 16 VJ slots with slot compression
ppp[1661]: tun0: IPCP:  PRIDNS[6] 10.11.12.13
ppp[1661]: tun0: IPCP:  SECDNS[6] 10.11.12.14
ppp[1661]: tun0: Command: /dev/ttyp1: quit
ppp[1661]: tun0: IPCP: deflink: SendTerminateReq(11) state = Req-Sent
ppp[1661]: tun0: IPCP: deflink: State change Req-Sent --> Closing
ppp[1661]: tun0: IPCP: deflink: RecvTerminateAck(11) state = Closing
ppp[1661]: tun0: IPCP: deflink: LayerFinish.
ppp[1661]: tun0: IPCP: Connect time: 11 secs: 0 octets in, 0 octets out
ppp[1661]: tun0: IPCP: 0 packets in, 0 packets out
ppp[1661]: tun0: IPCP:  total 0 bytes/sec, peak 0 bytes/sec on Thu Apr 24 13:39:49 2008
ppp[1661]: tun0: IPCP: deflink: State change Closing --> Closed
ppp[1661]: tun0: IPCP: deflink: RecvConfigNak(11), dropped (expected 12)
ppp[1661]: tun0: Phase: bundle: Terminate

No comments | Share on Facebook | Share on Twitter

src/share/zoneinfo updated to 2008b

Posted on 2008-03-25 09:00:09, modified on 2008-03-25 09:00:00
Tags: FreeBSD, zoneinfo

Commit of the day for src/share/zoneinfo:

Changes:
- Calcutta -> Kolkata
- Iraq DST changes
- Syria DST changes
- Saigon -> Ho_Chi_Minh
- Cuba DST changes
- New area America/Argentina/San_Luis

This is availabe in FreeBSD > 7.0, > 6.3 and > 5.5 and in the ports collection (as misc/zoneinfo).

No comments | Share on Facebook | Share on Twitter

src/share/zoneinfo updated to 2008a

Posted on 2008-03-10 09:00:09, modified on 2008-03-10 09:00:00
Tags: FreeBSD, zoneinfo

Commit of the day for src/share/zoneinfo:

- Chilis DST has been extended for 3 weeks.
- No leapsecond in 2008

This is availabe in FreeBSD > 7.0, > 6.3 and > 5.5 and in the ports collection (as misc/zoneinfo).

No comments | Share on Facebook | Share on Twitter

New tftp / tftpd implemetation for FreeBSD

Posted on 2008-01-31 20:00:00
Tags: Networking, tftp, FreeBSD

It all started when we got some new routers, which told me the following when trying to upload configuration or download images from it: The TFTP server doesn't support the blocksize option.

My curiousity was triggered, it took me some reading of RFCs and other documentation to find out what was possible and what could be done. Was plain TFTP very simple in its handshake, TFTP with options was kind of messy because of its backwards capability: The first packet returned could either be an acknowledgement of options, or the first data packet.

Going through the source code of src/libexec/tftpd and going through the code of src/usr.bin/tftp showed that there was a lot of duplicate code, and the addition of options would only increase the amount of duplicate code. After all, both the client and the server can act as a sender and receiver.

At the end, it ended up with a nearly complete rewrite of the tftp client and server. It has been tested against the following TFTP clients and servers:

Itself (yay!)
The standard FreeBSD tftp client and server
The Fedora Core 6 tftp client and server
Cisco router tftp client
Extreme Networks tftp client

It supports the following RFCs:

RFC1350 - THE TFTP PROTOCOL (REVISION 2)
RFC2347 - TFTP Option Extension
RFC2348 - TFTP Blocksize Option
RFC2349 - TFTP Timeout Interval and Transfer Size Options
RFC3617 - Uniform Resource Identifier (URI) Scheme and Applicability Statement for the Trivial File Transfer Protocol (TFTP)

It supports the following unofficial TFTP Options as described at http://www.compuphase.com/tftp.htm:

blksize2 - Block size restricted to powers of 2, excluding protocol headers
rollover - Block counter roll-over (roll back to zero or to one)

From the tftp program point of view the following things are changed:

New commands: "blocksize", "blocksize2", "rollover" and "options"
Development features: "debug" and "packetdrop"

If you try this tftp/tftpd implementation, please let me know if it works (or doesn't work) and against which implementaion so I can get a list of confirmed working systems.

For now, the new implementation can be found at as a port in net/freebsd-tftp until it has been imported back into the FreeBSD base system.

Show comment | Share on Facebook | Share on Twitter

src/share/zoneinfo updated to 2007k

Posted on 2008-01-01 18:00:00, modified on 2008-01-06 19:00:00
Tags: FreeBSD, zoneinfo

Commit of the day for src/share/zoneinfo:

MFV of tzdata2007k

Timezone data changes in this import:
- Add Argentinian DST changes
- Place SJH in the right location

This will be availabe in FreeBSD >= 7.0, >= 6.3 and >5.5 and in the ports collection (as misc/zoneinfo).

Updated: MFCed into RELENG_7_0 and RELENG_6_3 so it will be available for the releases of 6.3 and 7.0.

No comments | Share on Facebook | Share on Twitter

Getting rid of unused shared memory segments, message queues and semaphore sets - ipcrm(1)

Posted on 2007-12-26 17:00:00
Tags: FreeBSD, IPC

Thanks to a submmited patch of Callum Gibson the ipcrm(1) program now has the capabilities to wipe all unused shared memory segments, message queues and semaphore sets. You can either chose to specify the individually (e.g. only the message queues, or only the shared memory segments) or just wipe them all with the -W option.

This will be availabe in FreeBSD >7.0, >6.3 and >5.5.

No comments | Share on Facebook | Share on Twitter

FreeBSD and the Huawei E220 USB 3G Modem

Posted on 2007-12-14 21:00:00, modified on 2007-12-17 07:30:00
Tags: Huawei E220, FreeBSD, Networking, 3G

I'm the lucky owner of a Huawei E220 3G USB modem. For certain degrees of lucky that is: Getting it to work has been an interesting challenge.

The E220 is by default (FreeBSD 6.3-BETA) recognized as an umass(4) (USB Mass Storage Device) device. That's true, there is a memory disk in it. It is recognized as /dev/cd0 and you can mount it with mount_cd9660 /dev/cd0 /mnt, giving you 10 megabytes of space.

But that is not what you bought the E220 for. You want to use it as a modem. You need to change a couple things in your kernel to get it all working. ~~First, add a line to /sys/dev/usb/usbdevs:~~

    /* HP products */
    product HP2 C500                0x6002  PhotoSmart C500

    /* HUAWEI products */
    product HUAWEI MOBILE           0x1001  Huawei Mobile
   +product HUAWEI E220             0x1003  Huawei E220 HSDPA USB Modem

    /* IBM Corporation */
    product IBM USBCDROMDRIVE       0x4427  USB CD-ROM Drive

And to /sys/dev/usb/usba.c:
{ USB_VENDOR_OPTION, USB_PRODUCT_OPTION_GT3G }, /* Option GlobeTrotter 3G QUAD */ { USB_VENDOR_OPTION, USB_PRODUCT_OPTION_GT3GQUAD }, /* Huawei Mobile */ { USB_VENDOR_HUAWEI, USB_PRODUCT_HUAWEI_MOBILE }, +{ USB_VENDOR_HUAWEI, USB_PRODUCT_HUAWEI_E220 }, { 0, 0 } };
See the FreeBSD PR usb/118686 for a full patch.

Second, you have to disable the umass(4) device from your kernel configuration and rebuild a new kernel. Will this break things? Most likely, specially when you have USB disks and sticks. But you will load it as a module, which will undo the damage you just did to it. In your /boot/loader.conf, add the following lines:

    ubsa_load="YES"
    umass_load="YES"

ubsa(4) is the USB support for Belkin serial adapter. That sounds more like a modem. Next, reboot the machine and see if all modules are loaded correctly:

    # kldstat
    Id Refs Address    Size     Name
     1   20 0xc0400000 72e17c   kernel
     2    1 0xc0b2f000 e6a4     if_iwi.ko
     3    3 0xc0b3e000 2f9c     firmware.ko
     4    1 0xc0b41000 6cdc     ugen.ko
     5    1 0xc0b48000 75b4     umass.ko
     6    1 0xc0b50000 7958     ng_ubt.ko
     7    2 0xc0b58000 cb78     netgraph.ko
     8    1 0xc0b65000 2ef0     ubsa.ko
     9    2 0xc0b68000 4374     ucom.ko
    10    1 0xc0b6d000 5c304    acpi.ko
    11    1 0xc4868000 30000    iwi_bss.ko

Next, plugin your E220 and see what happens:

    ucom0: HUAWEI Technologies HUAWEI Mobile, rev 1.10/0.00, addr 2
    ucom0: Could not find interrupt in
    device_attach: ucom0 attach returned 6

~~Yes! No! Something is wrong. But a little bit of finger skill will resolve it:~~

~~At the USB modem side of the USB cable (not the computer side!), carefully pull the cable from the modem and when you see this on your screen, plug it back in:~~

    ucom0: at uhub1 port 1 (addr 2) disconnected
    ucom0: HUAWEI Technologies HUAWEI Mobile, rev 1.10/0.00, addr 2

~~It's loaded! If it doesn't work at the first go, try it a couple of times more. Once you are without the dreaded "Couldn't find interrupt in" message you are a happy person.~~

Check /dev/cuaaU0, it exists! If you have comms/minicom installed, you can do this:

    OK
    ATI
    Manufacturer: huawei
    Model: E220
    Revision: 11.117.06.00.100
    IMEI: 358191018517800
    +GCAP: +CGSM,+DS,+ES
    OK

And if you dial out, you will end up with a whooping 7.2Mbps connection;

    OK
    ATDT *90#
    CONNECT 7200000

Now it is time to train ppp(1). Add this to your /etc/ppp/ppp.conf:

    three:
	set device /dev/cuaU0
	set speed 57600
	set phone *99\#
	set authname
	set authkey
	set ifaddr 10.0.0.1/0 10.0.0.2/0 0.0.0.0 0.0.0.0
	set vj slotcomp off
	add default HISADDR

And dial:

    $ ppp three
    ppp> dial
    Ppp>
    PPp>

That's not good, there should be three capital P's... Going through the PPP log, you will see that the IPCP layer doesn't get initialized properly. Why? No idea. How to resolve it? Put your USB modem in a windows machine, run it once there and put it back into your FreeBSD machine. Why? No idea. It works. The USB modem didn't work with under MacOS/X neither until I did this trick. Why? No idea. It works.

Dial again:

    $ ppp three
    ppp> dial
    Ppp>
    PPp>
    PPP>

    $ ifconfig tun0
    tun0: flags=8051 mtu 1500
	    inet 119.11.32.164 --> 10.0.0.2 netmask 0xffffffff
	    Opened by PID 22997

    $ ping www.freebsd.org
    PING www.freebsd.org (69.147.83.33): 56 data bytes
    64 bytes from 69.147.83.33: icmp_seq=0 ttl=48 time=477.662 ms
    64 bytes from 69.147.83.33: icmp_seq=1 ttl=51 time=416.606 ms
    ^C
    --- www.freebsd.org ping statistics ---
    3 packets transmitted, 2 packets received, 33% packet loss
    round-trip min/avg/max/stddev = 416.606/447.134/477.662/30.528 ms

Your console and /var/log/messages will be spammed with "kernel: ucom0: usba_request: STALLED" messages for some reason, but it works.

Show 2 comments | Share on Facebook | Share on Twitter

FreeBSD FTP mirrors quality

Posted on 2007-12-06 17:00:00, modified on 2007-12-06 19:30:00
Tags: FreeBSD

At Statistics for FTP FreeBSD mirrors I have made an overview of how good the FreeBSD FTP mirrors are. Not a full overview, just for the ISO images directories, but it will give an indication of the quality of the mirroring.

For Australia is shows that at this moment in time ftp3.au.freebsd.org, or mirror.pacific.net.au, is the only one who is nicely mirroring everything, the rest is running behind or doing partly mirroring.

Scripts are available from the URL linked to above.

No comments | Share on Facebook | Share on Twitter

src/share/zoneinfo updated to 2007j

Posted on 2007-12-04 10:00:00, modified on 2008-01-06 19:00:00
Tags: FreeBSD, zoneinfo, iso3166

Commit of the day for src/share/zoneinfo:

MFV of tzdata2007j

Timezone data changes in this import:
- Add America/St_Barthelemy (BL) and America/Marigot (MF)
- Venezuela will move to -4:30 on 9 December 2007 instead of 31 December 2007

and of src/share/misc/iso3166:

Update with data from Newsletter VI-1 2007-09-21:

- Added SAINT BARTHELEMY (BL) and SAINT MARTIN (MF).

This will be availabe in FreeBSD >7.0, >6.3 and >5.5 and in the ports collection (as misc/zoneinfo) once the ports freeze has been lifted or use ports/118409 to update your system earlier.

Note: the iso3166 and the zoneinfo updates are MFCed into RELENG_7_0 and RELENG_6_3 so it will be available for the releases of 7.0 and 6.3.

No comments | Share on Facebook | Share on Twitter

tftpd -W option

Posted on 2007-11-26 10:00:00
Tags: FreeBSD, tftp

Commit of the day for tftpd(8):

Add the -W options, which acts the same as -w but will generate
unique names based on the submitted filename, a strftime(3) format
string and a two digit sequence number.

By default the strftime(3) format string is %Y%m%d (YYYYMMDD), but
this can be changed by the -F option.

What does this mean? That you don't have to worry about overwriting your precious previous saved router configuration files:

[/tftpboot] root@tftp>ls -al
-rw-r--r--   1 nobody  wheel   44048 Jun 22 08:52 hs2-bd8806.20070622.00
-rw-r--r--   1 nobody  wheel   45973 Jul 21 17:24 hs2-bd8806.20070721.00
-rw-r--r--   1 nobody  wheel   49140 Oct  4 21:49 hs2-bd8806.20071004.00
-rw-r--r--   1 nobody  wheel   49176 Oct  4 21:53 hs2-bd8806.20071004.01
-rw-r--r--   1 nobody  wheel   49177 Oct  4 21:54 hs2-bd8806.20071004.02

This will be availabe in FreeBSD >7.0, >6.3 and >5.5.
Patches will be available from src/libexec/tftpd/ in revisions:

Makefile: 1.10
tftpd.8: 1.22
tftpd.c: 1.38

No comments | Share on Facebook | Share on Twitter

HP DL380 Raid Controller Disk issues.

Posted on 2007-05-18 10:00:00
Tags: Adventures, FreeBSD, HP

Today for the first time in my life I had troubles setting up a normal FreeBSD machine due to the geometry of the disk. The machine has a Raid 6i card in it, and there are four 147Gb disks in a RAID5 configuration.

The device gets detected as:

da0: 420029MB (860220400 512 byte sectors: 255H 32S/T 65535C

Fdisk complains about it:

A geometry of 105419/255/32 for da0 is incorrect.

and picks:

DISK Geometry: 53546 cyls/255 heads/63 sectors = 860216490 sectors (420027MB)

Installing FreeBSD on that geometry goes without a problem. But at a reboot, it doesn't work anymore. Pressing F1 for FreeBSD at the bootmanager doesn't work, it just beeps.

Luckely Darius on #bsddev knew how to resolve this:

<Darius> also, can you get to the loader prompt on the CD after you have installed and type..
<Darius> unload
<aDrius> set currdev=disk1s1a:
<aDrius> boot -s
<Darius> then run boot0cfg /dev/da0

It works!

No comments | Share on Facebook | Share on Twitter

FreeBSD For All podcast has disappeared

Posted on 2007-05-02 17:00:00
Tags: FreeBSD, RSS

Today is a sad day in the world of podcasting. Well, for FreeBSD that is. It seems that the FreeBSD For All podcast has disappeared from the internet. It was one only user-driven FreeBSD related podcast. Copies of the show can still be found at the PodcastDirectory.com, but not sure how much longer they will be there.

No comments | Share on Facebook | Share on Twitter

FreeBSD Multimedia Resources list has moved

Posted on 2007-04-24 11:44:00
Tags: FreeBSD, RSS

I have reworked the implementation of the FreeBSD Multimedia Resources List. From a PHP script which parses everything when a webbrowser asks for it, I know have a Perl script which creates it once and the rest is static.

New features are tags in the articles and it also has a flexible design so it can be very easy modified for the different BSDs:

Unfortunately, the names of the files have changed a little bit to incorperate this:

http://www.mavetju.org/unix/multimedia.php is now http://www.mavetju.org/unix/multimedia/freebsd/multimedia.html
http://www.mavetju.org/unix/multimedia-rss.php is now http://www.mavetju.org/unix/multimedia/freebsd/multimedia.xml

With these new features I hope that the list will get incorperated in the websites of the varies *BSDs so that the list gets wider fame and I don't have to go from "If I only knew that this presentation was available three months ago..."

Show comment | Share on Facebook | Share on Twitter

/etc/resolv.conf in jails

Posted on 2006-12-11 09:04:18, modified on 2006-12-11 11:42:03
Tags: FreeBSD, DNS

I have been plagued by this error in some of my jails for a long time:

$ dig foo.bar
;; reply from unexpected source: 202.83.178.125#53, expected 127.0.0.1#53

telnet itself works fine, it's just that dig and friends give this strange error. What is also strange is that the tcpdump output doesn't reflect the settings in /etc/resolv.conf:

$ cat /etc/resolv.conf
search barnet.com.au
server 202.83.176.1

And the tcpdump output:

# tcpdump -ni lo0 port 53
11:28:45.204241 IP 202.83.178.125.57276 > 202.83.178.125.53:  15750 A? www.ibm.com. (29)
11:28:45.218305 IP 202.83.178.125.53 > 202.83.178.125.57276:  15750- 0/4/4 (203)

Of course this was a configuration issue. In /etc/resolv.conf, the right statement is nameserver, not server. But the resolver in the jail looked through the /etc/resolv.conf of the host which contains 127.0.0.1.

But the final question is: Where does it get 202.83.178.125 from? It is the IP address of the jail, to which 127.0.0.1 silently gets translated to. But the resolver still expects it to come from the 127.0.0.1 number, and is for that reason throwing the warning.

No comments | Share on Facebook | Share on Twitter

FreeBSD Multimedia Resources list

Posted on 2006-08-19 20:55:45, modified on 2006-08-19 21:36:18
Tags: FreeBSD, RSS

I became a little bit tired of giving out the same URLs to everybody each time somebody asked for a list with podcasts/vodcasts etc related to FreeBSD. So I made the FreeBSD Multimedia Resources list. See http://www.mavetju.org/unix/multimedia.php for more information, and there is an RSS feed for it too!

No comments | Share on Facebook | Share on Twitter

FreeBSD and Citrix MetaFrame

Posted on 2006-03-17 10:31:16, modified on 2006-03-17 11:16:56
Tags: Computers, Citrix, FreeBSD

At work we got a new toy: a Citrix MetraFrame Presentation Manager. In reality it is nothing more than a frontend for a Windows session, like you can get with RealVNC or Remote Desktop. Well, the difference is that more than one person can use it at the same time, and they all have their own desktop and settings. Not even a desktop, just a bunch of icons of pre-installed programs. Anyway, to the FreeBSD story.

Access to the MetaFrame website is easy, just login with your windows username and password. But then, it says "Your client platform is not supported.". This is a false alarm, but confusing.

For the general population, MetaFrame automatically picks the Java client. But not for the FreeBSD machines. At the top right of the Applications window there is a button to customize the user preferences. Client on the Client Preferences settings link. There you can choose between "Local client" and "Client for Java".

"Client for Java" forces the website to use the Java client, just like the general population gets. Works like a charm.

For "Local client", you need to install net/citrix_ica. There are two tweaks I needed to make before it all worked here. First one is that I had to configure a help for .ica files: MIME-Type is application/x-ica, application is /usr/local/bin/wfica. The second one was that I had to add the certificate of our SSL provider to the directory /usr/local/ICAClient/keystore/cacerts (note that the extension should be .crt, and that the name of it should be the same as wfica is complaining about. Use "openssl x509 -noout -text -in foo.crt" to check this).

And it all works now, both ways and without problems.

No comments | Share on Facebook | Share on Twitter

When routing goes bad....

Posted on 2004-07-02 10:54:01, modified on 2006-01-09 16:29:22
Tags: Networking, FreeBSD

At BarNet, our backup link to the internet goes via a different ISP which is charged per megabyte. Being the backup link, this normally doesn't give much problems. Except when we suddenly got a nasty bill for it. Time for some investigation... (read on)

At this moment, we have say four class C networks (192.168.0.0/24 - 192.168.3.0/24). The first two are allocated, the last two are in use for later. Our IP space is part of the IP space of the backup ISP. Our default gateway is pointing to our normal ISP, and we route the IP space of the backup ISP directly to our backup ISP. Or in a picture:

0.0.0.0/0        -> normal ISP
192.168.0.0/16   -> backup ISP
192.168.0.0/24   -> LAN A
192.168.1.0/24   -> LAN B

What happens when a packet comes in for 192.168.0.1? It gets forwarded to the LAN A. What happens when a packet for 192.168.1.1 comes in? It gets forwarded to the LAN B. And what happens when a packet for 192.168.2.1 comes in? The network 192.168.2.0/24 is not in the routing table, so it takes the next smallest one: 192.168.0.0/16. And the packet goes happily on its way to the backup ISP. But then, it gets send back to us, because the backup ISP knows that 192.168.2.0/24 is on our network. It keeps bouncing between the backup ISP and us until its TTL has expired. Each other bounce is charged to us...

The solution is to add an entry for all our networks in the routing table of one of the machines which gets null-routed: routed into a "network"-device which just discards all packets. Don't go playing with firewall rules, that will only cause problems later when the spare IP space gets used and things suddenly don't work anymore and nobody knows why.

On FreeBSD, the discard device is called disc(4). Just kldload if_disc and you can ifconfig ds0. An IP address is not necessary (trying to add one on FreeBSD 4.7 causes the machine to panic, but with 4.10 it worked). In your /boot/loader.conf, add a line with if_disc_load="YES". In your /etc/rc.conf, add a line with cloned_interfaces="ds0". And as the last one, add a line to your /etc/rc.conf with route_discard="192.168.0.0/22 -interface ds0".

From that moment, your routing table will look like:

0.0.0.0/0        -> normal ISP
192.168.0.0/16   -> backup ISP
192.168.0.0/22   -> ds0
192.168.0.0/24   -> LAN A
192.168.1.0/24   -> LAN B

and there will be no more billing for unwanted traffic from the backup ISP!

No comments | Share on Facebook | Share on Twitter

Sound hickups during disk access

Posted on 2004-03-23 13:52:12, modified on 2006-01-09 16:29:21
Tags: Computers, FreeBSD

Recently I changed two things on my computer. 1. I upgraded to FreeBSD 5.2.1 and 2. I installed a bigger harddisk.

When using the soundcard (playing MP3s, listening to the radio, watching movies), the sound got bargled (hickupped, prrrrrtzed, whatever you call it) for a split second, after which it continued as normal.

Annoying, specially if you are singing along. Guido van Rooij (former collegue, fellow FreeBSD user etc) told me to change the buffersize on the sound card to 16Kb:

[~] edwin@k7>sysctl hw.snd.pcm0.buffersize
hw.snd.pcm0.buffersize: 16384

To do this, requires a change in /boot/device.hints:

[~] edwin@k7>grep pcm /boot/device.hints
hint.pcm.0.buffersize=16384

and a reboot. Since this change my MP3s play smoothly.

Show 2 comments | Share on Facebook | Share on Twitter

Multiple applications accessing /dev/dsp under FreeBSD

Posted on 2004-03-06 15:23:22, modified on 2006-01-09 16:29:21
Tags: Computers, FreeBSD

[~] root@k7>sysctl hw.snd.pcm0.vchans
hw.snd.pcm0.vchans: 0

If you set this to a higher number (I have four), multiple applications can access the /dev/dsp device at the same time:

[~] edwin@k7>lsof -n | grep dsp
mplayer   16352 edwin    9w    VCHR  30,131075 0t40194048      218 /dev/dsp0.2
xmms      99819 edwin   10w    VCHR       30,3 0t22636544       34 /dev/dsp0.0

Finally I can play games and listening to the radio at the same time!

No comments | Share on Facebook | Share on Twitter

Upgrading via cvsup

Posted on 2004-01-22 11:47:45, modified on 2006-01-09 16:29:21
Tags: Computers, FreeBSD

Up to now, I always upgraded my FreeBSD computers via the mini-ISO cdroms provided by the FreeBSD team. Last week, due to circumstances, I had to upgrade them via cvsup and to build the new OS from scratch. A small step for me, a huge step for ME!

What were the circumstances?

At BarNet, there are about eight remote computers. On uninhabited places, like in cupboards, behind the copier, three meters above the floor and so on. Not easily reachable :-)

Also, the computers were running a huge range of OS versions, ranging from FreeBSD 4.2 to FreeBSD 4.9. With matching the OS version with the date the OS version was released you could figure out when the machine came into operation.

And the last thing was that we are going to provide ADSL backup features, which means that when the primary link fails, the traffic will go via a slower link. And zebra, the routing daemon we were going to use, doesn't really work with FreeBSD versions lower than 4.6.

Make the new system

Step one: be brave. Be very brave.
copy /usr/share/examples/cvsup/supfile-4.8 to /root/stable-supfile and change the fields "host" and "release". For host I used cvsup.au.freebsd.org, for tag I used RELENG_4_8_0_RELEASE.
Run cvsup: cvsup -g /root/supfile-4.8
Chdir to /usr/src and run "make -j4 buildworld" and "make -j4 buildkernel"
That is enough for now. Nothing has been damaged yet. You can still chicken out.
Run "make installkernel" and "make installworld". From now on programs can start failing. Reboot quickly!
After the machine has come back (it's unbelievable but it will come back!), run mergemaster.sh in /usr/src/usr.sbin/mergemaster to update your configuration files. Make sure you don't overwrite your /etc/passwd and /etc/master.passwd files!
Make a kernel specific for this machine and install that one.
Reboot again

Was that now so difficult? No. So why have I struggled in the last seven years with cdroms? Must be because I had never done it before.

What went wrong

Of course things can go wrong. And will go wrong.

During one night I had xterms open to all machines which had to be upgraded (erm... all of them), running the make buildXXXX. With -j4, the load on the machine will swing between 5 and 10. We use nagios to monitor the systems, and it complained that their loads was too high. And since I'm not the only one receiving these alerts, I got phonecalls saying "what's wrong, what's wrong?". Inform your fellow people before you start.

First machine I upgraded went without a glitch. The second machine I did didn't come back up. So far for a foolproof solution. When I went to the console (next day early in the morning): fsck had failed. With other words, the harddisk is broken.

Two machines which had been given more networks cards recently didn't come back properly. It seemed the network cards were configured properly, but and the ifconfig_ statements added to /etc/rc.conf, but they had their (old, obsolete) "network_interfaces" variable in /etc/rc.conf not updated. A manual ifconfig and editing of /etc/rc.conf fixed it. (Don't forget to reboot afterwards to see if it works again, or at least restart the DHCP daemon since that daemon doesn't automaticly grabs new interfaces).

At the end

From now on, no more binary upgrades anymore for me, just cvsup and make! Yay!

Show comment | Share on Facebook | Share on Twitter