; <<>> DiG 9.3.4 <<>> +dnssec web.pixaco.se @83.169.184.161
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; ANSWER SECTION:
web.pixaco.se. 0 IN A 204.9.89.60

Beside that, this behavour breaks the whole DNS, since many mechanism rely on a negative answer. The most visible effect for the users is, that when having a typo on surfing, he will forwarded to http://suche.kabeldeutschland.de/de.kde.assist/?domain=<domainyoutypedinyourprompt>. Since 204.9.88.0/21 is located at our transatlantic friends from US, there might be some problem with leaking privacy informations. I don’t feel happy, if I had a typo in my URL and getting listed for it on any terror list or providing the newest porno links to my american friends inside the organisations with the tree capitals.

All that for getting some extra money, but racing pricedumping for connectivity, this sucks a lot.
If you are a customer and feel pissed, you can send a friendly note to them:

Kabel Deutschland Vertrieb und Service GmbH & Co. KG
Beschwerdestelle
99116 Erfurt
kundenservice@kabeldeutschland.de
Fax: 01805299925

A quick and dirty workaround for dnsmasq maybe to add “bogus-nxdomain=204.9.89.60″ to your config file. This doesn’t fix the DNSSEC problem.
The problem also pops up at dns-operations and there are traces at google too.

[UPDATE] Over 1 year later zdnet.de discoverd the problem.

Would you like to enter the initial configuration dialog? [yes/no]:
Loading pxelinux.0 from 10.42.10.50 (via FastEthernet4/0/0): !!!
[OK - 13156 bytes]

So the box took an IP via DHCP and tried to netboot. (Un)fortunately it only breaks my terminal, so no worries! ;)

• only bind9 (>= 9.3) and NSD privides support (yet)
• bandwidth will be increased 2-3 times with max. key size
• increased memory usage depending on your server software
• operational costs will increasing dramaticaly due significant higher amount of regular work
• more computing power (hardware) needed to generate dnssec ready zones and signing
• unknown influence on resolving nameservers (load/memory/bandwidth)
• chain of trust ends at resolving nameserver and is not provided to enduser

Since the last issue isn’t solved (yet), it doesn’t make any sence for me to invest resources into setting up DNSSec infrastructur, cause the end user would not recognize if the communication with the resolving nameserver or the resolving nameserver itself is taken over.

Any complaints and/or hint? Did I missed something?

At first you need make a copy of policyd-weight and modify it, since Robert didn’t implement a switch to specify a config file (yet):

# cp policyd-weight policyd-weight-instance2
# sed “s/\/policyd-weight.conf/\/policyd-weight-instance2.conf/” \
policyd-weight-instance2

Required changes to the config file:

# echo “$syslog_ident = \
“postfix/policyd-weight-INSTANCE2″;” >> \
/etc/policyd-weight-mx.conf
# echo “$SPATH = \
$LOCKPATH.’/polw-instance2.sock’;” >> \
/etc/policyd-weight-mx.conf
# echo “$PIDFILE = \
“/var/run/policyd-weight-instance2.pid”;” >> \
/etc/policyd-weight-mx.conf
# echo “$TCP_PORT = \
12526;” >> /etc/policyd-weight-mx.conf

The difference in my case is to not score “bogus_mx_score”, which may cause trouble when mails coming in from backup MX:

# echo “@bogus_mx_score = (0, 0 );” >> \
/etc/policyd-weight-mx.conf

Create aliases for groups of access restrictions in /etc/postfix/main.cf:

smtpd_restriction_classes = policy1,
                            policy2,
policy1 = check_policy_service inet:127.0.0.1:12525
policy2 = check_policy_service inet:127.0.0.1:12526

Create “/etc/postfix/ip_rules.cidr”:

# echo “127.0.0.1 policy1″ > /etc/postfix/ip_rules.cidr
# echo “127.0.0.2 policy1″ >> /etc/postfix/ip_rules.cidr
# echo “0.0.0.0/0 policy2″ >> /etc/postfix/ip_rules.cidr

Add “check_client_access cidr:/etc/postfix/ip_rules.cidr” at the end of “smtpd_recipient_restrictions” in /etc/postfix/main.cf

In this scenario you can have different access policies based on the client ip. It is also possible to base it on client reverse dns with help of pcre maps and recipient/sender address and hash maps

So … after more than one hour googling I found the following in the broadcom kernel module source:

if (val && strstr(v, "psk")) {
val = (strstr(v, "psk2") ? 0x84 : 0x4);
v = nvram_safe_get(wl_var("wpa_psk"));
if ((strlen(v) >= 8) && (strlen(v) < 63)) {

bcom_ioctl(skfd, ifname, WLC_SET_WPA_AUTH, &val, sizeof(val));

if (nvram_match(wl_var("mode"), "wet")) {
/* Enable in-driver WPA supplicant */
wsec_pmk_t pmk;

pmk.key_len = (unsigned short) strlen(v);
pmk.flags = WSEC_PASSPHRASE;
strcpy(pmk.key, v);
bcom_ioctl(skfd, ifname, WLC_SET_WSEC_PMK, &pmk, sizeof(pmk));
bcom_set_int(skfd, ifname, "sup_wpa", 1);
}
}
}

So … this means, that the WPA-PSK length has to be >= 8 and < 63, mine was 65. This wasn´t a problem yet, cause I used the routers only in AP mode, where this restriction doesn't effect. Shorting the WPA-PSK length 62 did the trick!

Successfull was the following modifications to factory (linksys) defaults:

nvram set vlan0ports=”0 1 2 5*”
nvram set vlan1ports=”4 5*”
nvram set vlan0hwname=”et0″
nvram set vlan2ports=”3 5″
nvram set vlan2hwname=”et0″
nvram set dmz_ifname=”vlan2″
nvram set lan_ifname=”br0″
nvram set lan_ifnames=”vlan0″
nvram set wan_ifname=”ppp0″

Now the door is open to extend the functionality of the openwrt router

# df
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/root 7296 3420 3876 47% /
none 15276 36 15240 0% /tmp

Hrhrhrhr … :-) Disassemble photos can be found here

Don´t ask how, but we got some units to europe.

The first thing we does, was to install openwrt and to try debridge the switch to have multiple interfaces instead. We was able to remove ports from the switch, but cant create additional working vlans like on WRT54G. So at this point its useless for our purpose. But we will start exploring as son as possible we have a running serial console.

Since on the old system is running kernel 2.4.x at the time of setup the only option was to use the capi driver and some hacks with hylafax to get all running. I don’t wonna look deeper into the old setup, to prevent to get mad. Anyways … an other setup was a faxserver. This was implemented also with the capi driver and capisuite.

So I was going straight forward and installed the capi driver on the known way.

Following my own install documentation I was really surprised that the hisax driver was already in place and the capi driver of the card was unable to load.

Okay … unloading the hisax stuff and loading the fcpci module did work, but the realy annoying part was, that the hisax modules got loaded on every reboot. Deleting the modules out of /lib/modules wasn’t an option, cause they will reappear with the next kernel update. I decided to purge the hotplug and discover packages, with the result, that the hisax modules got loaded on boot (and other modules) anyways. It was looking like running any discover or hotplug process. So I double checked:

# COLUMNS=200 dpkg -l | grep hotplug
# COLUMNS=200 dpkg -l | grep discover
#

Hmmm …. I didn’t got it. All the modules where autoloaded right before mounting the filesystems..

# ls -la /etc/rcS.d/ | grep -v S[01457] | grep ^l
lrwxrwxrwx   1 root root   27 May 17 11:28 S20module-init-tools -> ../init.d/module-init-tools
lrwxrwxrwx   1 root root   18 May 17 11:28 S20modutils -> ../init.d/modutils
lrwxrwxrwx   1 root root   20 May 17 11:28 S30checkfs.sh -> ../init.d/checkfs.sh
lrwxrwxrwx   1 root root   19 May 17 11:28 S30procps.sh -> ../init.d/procps.sh
lrwxrwxrwx   1 root root   21 May 17 11:28 S35mountall.sh -> ../init.d/mountall.sh
lrwxrwxrwx   1 root root   15 May 17 11:28 S35quota -> ../init.d/quota
lrwxrwxrwx   1 root root   21 May 17 11:28 S36mountvirtfs -> ../init.d/mountvirtfs
lrwxrwxrwx   1 root root   20 May 17 11:28 S38resolvconf -> ../init.d/resolvconf
lrwxrwxrwx   1 root root   18 May 17 11:28 S39ifupdown -> ../init.d/ifupdown
#

Okay … I gave up. If hisax is running, lets check if yaps isn’t working with it. I copied the yaps.rc from the running system, modified the MSN and run a test:

Trying to open /dev/ttyI0 for modem standard
Unable to dial E2-0179

Okay … since in the isdnlog appearing enties from the bus, there must be a pitfall anywhere and I tried to start a connection with minicom …. successfull.
I remembered than there was a problem with the lock-prefix when I did setup yaps some years ago. So I found a lock “/var/lock/LCK..isdnctrl0″ existing and did set “lock-prefix /var/lock/LCK..” in /etc/yaps.rc.

[Hangup]
[Send] ATZ
[Expect] ATZOK got OK

HAHA!! Mission completed .. :) But the big question is … why are the modules autoloaded?