Searched the archives and found other mentions of this error but no solution. I have a Solaris 8 server with the Hobbit client reporting to the Hobbit server, and everything works except the netstat trend graph. I made sure Hobbit generates the netstat.rrd file itself, and verified that it has the correct fields: $ rrdtool dump netstat.rrd |grep "<name>" <name> udpInDatagrams </name> <name> udpOutDatagrams </name> <name> udpInErrors </name> <name> tcpActiveOpens </name> <name> tcpPassiveOpens </name> <name> tcpAttemptFails </name> <name> tcpEstabResets </name> <name> tcpCurrEstab </name> <name> tcpOutDataBytes </name> <name> tcpInInorderBytes </name> <name> tcpInUnorderBytes </name> <name> tcpRetransBytes </name> <name> tcpOutDataPackets </name> <name> tcpInInorderPackets </name> <name> tcpInUnorderPackets </name> <name> tcpRetransPackets </name> But viewing a debug output of rrd-data.log shows that something is making it think there should only be 11 fields: 2006-10-13 19:18:18 Want msg 667, startpos 66490, fillpos 66490, endpos -1, usedbytes=0, bufleft 461893 2006-10-13 19:18:22 hobbitd_rrd: Got message 667 @@data#667|1160767102.598295|10.x.x.x||x.x.x.x|netstat 2006-10-13 19:18:22 startpos 72703, fillpos 72703, endpos -1 2006-10-13 19:18:22 RRD update param 00: 'rrdupdate' 2006-10-13 19:18:22 RRD update param 01: '/cust/bbh/data/rrd/x.x.x.x/netstat.rrd' 2006-10-13 19:18:22 RRD update param 02: '-t' 2006-10-13 19:18:22 RRD update param 03: 'udpInDatagrams:udpOutDatagrams:udpInErrors:tcpActiveOpens:tcpPassiveOpens:t cpAttemptFails:tcpEstabResets:tcpCurrEstab:tcpOutDataBytes:tcpInInorderBytes :tcpInUnorderBytes' 2006-10-13 19:18:22 RRD update param 04: '1160767102:1580411:5594723:0:113952:19256340:17330:36082:7:653169856:440119 035:9398449:159635980:26380336:13186666:30559:612744' 2006-10-13 19:18:22 RRD error updating /cust/bbh/data/rrd/x.x.x.x/netstat.rrd from x.x.x.x: expected 11 data source readings (got 16) from 1160767102:1580411:5594723:0:113952:19256340:17330:36082:7:653169856:4401190 35:9398449:159635980:26380336:13186666:30559:612744:... Where is "param 03" coming from? From some configuration on the client side?