Archive for the ‘network’ Category

Windows 7, McAfee Firewall and SmartPhone-Sync

Thursday, December 24th, 2009

Windows 7, McAfee Firewall and SmartPhone-Sync - an Adventure. After I installed Windows7 successfully on my Samsung NC10 ("Nessie"), as described in another post in this blog, I wanted to sync my phone with it. I knew how it worked with XP. And I knew this would not help me a bit with Windows 7.

All I had, was the description how to get McAfee and ActiveSync up an running, which worked fine with Windows XP. But with Windows 7, ActiveSync is no longer required, nor is it possible to install it. Windows 7 comes with the Windows Mobile Device Center. What you probably need is the 6.1-update of the WMDC, but that's it.

At the time I was looking for information what I would need to get the SmartPhone-sync working without having to turn off the firewall completely everytime, I found nothing, no matter what keywords I fed into google. So I opened up the old description-page about McAfee and ActiveSync, and added the port that was stated there to the list of system-services:

- Service-name       : SmartPhone Sync
- TCP In/out         :   26695
- Open to a computer
   or network that is: Standard (including Trusted)

Then I looked for Apps on my computer that sounded like they might do what the ActiveSync-Apps did. I found a single 100%-match:

ceappmgr.exe,

in the directory

C:\Windows\WindowMobile .

I added it with Full Access to McAfee's Program-list. Next, I looked at the other executables in that directory. I added

  • wmdcBase.exe
  • WmdHost.exe

And tried again. It did not work. I looked through several more directories, added and removed several applications that looked promising to solve the problem, but nothing helped. Then I looked at the log-file generated by the McAfee-firewall, and noticed, that the IP 169.254.2.1 tried to access my computer through ICMP ping (which the firewall blocks), and tcp-port 990, commonly used by FTP for the control-channel when using TLS/SSL. I remembered both the IP and the port from my experiments with syncing the SmartPhone with linux, and decided to add this IP as "trusted" (which is possible directly from the log-entry).

I tried syncing again - and this time it worked.

Tags: , , , , , , , , , , , , , , , , , ,
Posted in ActiveSync, Configuration, McAfee, Microsoft, NC10, Samsung, Win7, Windows Mobile Device Center, experiments, gadgets, mda, mobile, netbook, network, operating system, smartphone, smartphone-experiments, synchronization, windows | 2 Comments »

Webserver switched from lighttpd to nginx

Saturday, December 5th, 2009

For some time now, I have been experiencing weird bugs with my webserver. I was running a lighttpd, version 1.4.22. Two annoying bugs occurred:

The first was more a nuisance when uploading files through a POST, which resulted in error 417 "Expectation failed" on the first attempt (while on the second it worked).

The second bug resulted in a reproducible denial-of-service, as it crashed the webserver. It occurred whenever a firefox-webbrowser attempted to connect to the server through HTTPS.

I hoped these bugs to be solved by upgrading from 1.4.22 to 1.4.23 and 1.4.24, but that did not happen. As I needed a solution to these bugs, I decided to switch from lighttpd to nginx.

The transition went surprisingly smooth. The configuration is a bit more complicated as it was with lighttpd, but easily set up and quite good explained on nginx's website, too.

Now, nginx runs all my websites, interacts with PHP through FastCGI, and problems seem to be gone.

Tags: , , , , , ,
Posted in internet, lighttpd, netbsd, network, nginx, server | No Comments »

netbsd.org online again

Friday, April 10th, 2009

Since Thursday, 9th April 2009, 17:00 UTC internet, landline and cellular phone services seem to be restored. That means netbsd.org is available again :)

For more details, see the appropriate articles on sfgate.com and cnet.

Tags: , , , , , , , ,
Posted in connection, internet, netbsd, network | No Comments »

netbsd.org down due to cut fiber-optic cables

Thursday, April 9th, 2009

Since Thursday, 09th April 2009, 01:30 a.m. PDT netbsd.org and quite a lot other hosts and services like landline and cellular telephone were knocked out, as "vandals" cut fiber-optic cable lines in two different locations around southern Santa Clara County, in Santa Cruz and San Benito counties and along the Peninsula.

See sfgate.com and cnet for more information.

Tags: , , , , , , , ,
Posted in connection, internet, netbsd, network | No Comments »

Windows-Update and Proxies

Tuesday, April 7th, 2009

After a discussion on IRCnet, I decided this topic might be worth a blog-post: How do I get Windows Update on Windows XP Home to work with proxies?

Windows XP Professional seems to accept the Administrator's Proxy-Settings automagically, but Windows XP Home doesn't. If you have a network that only permits HTTP-Access through a configured proxy, you have a problem: Windows XP Home won't update, because it attempts a direct connection to Microsoft's servers.

My own setup at home is like this: I have a Cisco C836 Router, which ACL's prohibit any traffic not coming from the proxyhost, or being from certain selected reserved protocols. The proxyhost is a NetBSD 5.0 RC3 Box (see this page and this post), running a Squid 3.0 Web-Proxy.  Since I needed to update my XP-Home-running NetBook, I found a simple solution to this problem some time ago: each Windows comes with a small tool named "proxycfg". All you need to do is call it appropriately, and even Windows XP will update through the proxy like a charm.

This is the help-output from proxycfg:

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\>proxycfg -?
Microsoft (R) WinHTTP Default Proxy Configuration Tool
Copyright (c) Microsoft Corporation. All rights reserved.

usage:

    proxycfg -?  : to view help information

    proxycfg     : to view current WinHTTP proxy settings

    proxycfg [-d] [-p <server-name> [<bypass-list>]]

        -d : set direct access
        -p : set proxy server(s), and optional bypass list

    proxycfg -u  : import proxy settings from current user's
                   Microsoft Internet Explorer manual settings
                   (in HKCU)

C:\>

If you have configured the Internet Explorer to use the proxy, you can simply call

 C:\> proxycfg -u

And the settings will be used. If you don't have the IE configured (which is a wise decision if you don't use it), you need to specify the proxy using the -p switch. In my case, this would look like this:

 C:\> proxycfg -p http://proxy.home.nifelheim.info:3128

After this, Windows Update will use these settings and you can update your machine.

Tags: , , , , , , , , ,
Posted in Configuration, Microsoft, Windows Update, XP, computer, connection, firewall, internet, network, operating system, proxy, update, windows | No Comments »

Nidhoegg: Updating a Security Host to NetBSD 5.0 RC3

Monday, April 6th, 2009

My network at home is secured against attacks from outside (and inside as well) by a strict set of ACLs within my Cisco C836 Router, and a SUN Ultra-5 serving as a proxy-host for several protocols. Until recently, this Machine was running a NetBSD 3.0.1 Userland with a self-compiled 3.1RC2 Kernel. It's pkgsrc-installed applications were also just as outdated, and so I decided to upgrade the whole box.

Usually, when computers engaged in securing your networks are to be upgraded, one goes for stability, security and definitely not for the newest OS-Version. In this case though, because of "RC" in NetBSD does not mean "development" (that would be "-current"), and because NetBSD 5.0 has certain features NetBSD 4.0.1 does not have, i.e. wapbl, I decided to really go and try NetBSD 5.0RC3. Following is a report about how the upgrade-process worked out...  :)

The Upgrade

Installing NetBSD 5.0RC3

I downloaded the bootable ISO-image from a french mirror-server, because either I was too blind, or the german mirrors currently do not have NetBSD-daily-images. After burning the image onto a CD, making some final backups, and sending a small prayer to /dev/null, the almighty Computer-God, I rebooted the machine. Starting from CD on a SPARC-box is usually as easy as nothing else. After System-Initialization (a.k.a POST on PCs), simply press Stop-A, and at the OK-Prompt enter

OK> boot cdrom

This time, however, the system told me that there was a problem reading the device. I remembered having had problems with the concurrent use of CD-ROM and Harddisk, and opened the Ultra-5. As I remembered, the CD-ROM-Drive was unplugged. I reattached it, and voila, now it worked.

So I ran the installer, partitioned my 8GB Harddisk in a single partition using FFSv2 with the option "log" enabled. This option was introduced by the wapbl-driver donated from Wasabi Systems Inc., and significantly improved by the NetBSD-developers. It provides a journalling filesystem on top of FFSv2, and improves the overall-performance of the filesystem as well. What I was ignorant of at this time of the process was the fact that the sparc64-port of NetBSD does not boot from FFSv2, because it has some issues with the different superblocks of FFSv2. Because I did not notice the culprit to be FFSv2, I tried several things, before finally using FFSv1 for the root-partition ("/"), and splitting up the partitions like this:

Filesystem        Size  Mounted on
/dev/wd0a         1.0G  /
/dev/wd0d         2.4G  /var
/dev/wd0g         2.9G  /usr
/dev/wd0e         482M  /home
mfs:165            62M  /tmp
/dev/wd1d          28G  /data

All partitions (except /tmp and / ) are using FFv2/wabbl (option log). The drive wd1 was added later after the installation process was finished and the CD-ROM drive was unplugged again. It's partition wd1d is using FFSv2 with wapbl, too, of course. :)

I added the log-option to the root-partition using FFSv1, too, just as a test.  mount(8) tells me, it is using the option, though I can hardly imagine that. wapbl(4) states about FFSv1 and the log-options this:

WAPBL requires the super block to be in the UFS2 format. Older FFSv1 file systems will need to be updated to the newer super block layout with the -c option to fsck_ffs(8).

Since I definitely did not update the superblocks (remember the booting-issue), and the machine definitely is booting now, I don't trust mount(8)'s output in this regard anymore, and have changed the option for the root-partition from log to softdep.

Note: log and softdep are mutual exclusive and lead in RC3 to a kernel-trap, though the kernel claims to ignore softdep. I have already submitted a problem report regarding this issue (kern/41161).

Configuring and Installing Packages

Now after the installation was completed, I started to download the pkgsrc-current tarball, again from the french-server since the german servers do not seem to mirror them as well. After untarring pkgsrc into /data, I set some CFLAGS, since I like to squeeze out every bit of performance available, as long as it does not break the system. My CFLAGS on the Ultra-5 look like this:

CFLAGS=-mcpu=ultrasparc -mtune=ultrasparc -m64 -mvis -O3 \
       -funroll-loops -fomit-frame-pointer

Of course the CXXFLAGS are equal to CFLAGS. :)

Now I bootstrapped pkgsrc (I know that on NetBSD this is not necessary, but out of a habit, and because the mk.conf is automatically generated and the tools are compiled with the above CFLAGS as well, I do it. It's a matter of taste, and according to some people probably of waste (of time) as well, but I don't mind :) ). Parallel to the bootstrapping, I configured the DHCP-, NTP- and SSH-server that came with NetBSD-base and launched them, so that those were already up and running again.

After that was done, I started installing the services I required:

  • misc/screen
  • net/bind9 - name-server
  • net/dante - socks-proxy
  • www/squid30 - webproxy
  • www/adzap - advertisement-zapper for squid
  • net/ra-rtsp-proxy - real-audio rtsp-proxy

With screen installed, I left the machine to itself and changed into the more comfortable living-room and my laptop. I ssh'ed to nidhoegg, launched screen, and continued from there with installing the apps in the list above. ntpd and named9 are running chrooted, btw.

I mentioned www/adzap in the list above, a squid-redirector I came to love over the last years while using squid 2.x . Sadly, it is incompatible to squid 3.0, obviously because the way squid talks to its redirectors has changed significantly. May be, if I find the time, I will look into this, and patch it so that is work with squid 3.0, too. Currently, adzap is not in use anymore, because the adzap-processes were dying so fast that browsing was impossible.

But before I could use the squid at all, I had to build my own NetBSD-kernel. Why, you might ask. The answer is simple: because I use diskd as storage-method, and diskd requires the following options set in the kernel, which aren't in GENERIC:

options         SYSVMSG         # System V-like message queues
options         SYSVSEM         # System V-like semaphores
options         SYSVSHM         # System V-like memory sharing

options         SHMMAXPGS=8192
options         MSGMNB=16384
options         MSGSSZ=64
options         MSGTQL=512

Ok, since NetBSD 4.99.35 this could be set through sysctl(8) and the kern.ipc.* variables, but I was not aware of that before writing this post. And besides, it was a good test / experiment to cross-compile a SPARC64-Kernel on an x86-System (I used my primergy-monster to compile the kernel). The kernel was build in about half an hour. Here is the report:

===> Summary of results:
         build.sh command: ./build.sh -m sparc64 -u -N 2 -U   \
                -T obj.sparc64/tooldir -D obj.sparc64/destdir \
                -R obj.sparc64/releasedir -V OBJMACHINE=1 -j8 \
                kernel=NIDHOEGG
         build.sh started: Sun Apr  5 18:16:21 CEST 2009
         NetBSD version:  5.0_RC3
         MACHINE:         sparc64
         MACHINE_ARCH:    sparc64
         Build platform:  NetBSD 4.0 i386
         HOST_SH:         /bin/sh
         TOOLDIR path:    /usr/build/src/obj.sparc64/tooldir
         DESTDIR path:    /usr/build/src/obj.sparc64/destdir
         RELEASEDIR path: /usr/build/src/obj.sparc64/releasedir
         makewrapper:     /usr/build/src/obj.sparc64/tooldir/
                                           bin/nbmake-sparc64
         Updated /usr/build/src/obj.sparc64/tooldir/bin/
                                          nbmake-sparc64
         Building kernel without building new tools
         Building kernel:  NIDHOEGG
         Build directory:  /usr/build/src/sys/arch/sparc64/
                               compile/obj.sparc64/NIDHOEGG
         Kernels built from NIDHOEGG:
          /usr/build/src/sys/arch/sparc64/compile/
                       obj.sparc64/NIDHOEGG/netbsd
         build.sh ended:   Sun Apr  5 18:42:30 CEST 2009
===> .

Of course the building of the toolchain is not included in this report, it's solely the kernel. I forgot to log how long that took, but from experiences with earlier NetBSD 5.0 builds (though for x86-platform), I can say that is usually takes about an hour.

The compilation went through without incident, and the kernel booted like a charm.

Squid was started and after the adzap-issue was identified and the adzap-call was removed from squid's configuration, all worked fine.

Conclusion

All in all it was a smooth process. The small problems that came up were quickly solved, some of them were caused by me being tired and inattentive, others because I had to learn that things do not always work as I wished them to (e.g. booting from FFSv2 and squid-3.0/adzap).

Since sunday, nidhoegg is running stable and fast, and yes, while copying files between disks, I do really think that wapbl's performance-improvements are recognizable. I copied several large files, and though I did not have measured the time, it felt way faster than on FFSv1, which was used on nidhoegg while running NetBSD 3.1RC2.

For all interest in the dmesg-output, read nidhoegg's page.

Tags: , , , , , , , , , , , , , , , , , ,
Posted in BSD, FFS, Kernel, NetBSD 5.0RC3, SPARC, SPARC64, SPARCstation, Sun, Ultra 5, computer, firewall, netbsd, network, opensource, operating system, pkgsrc, server, update, upgrade, wapbl | No Comments »

What’s up with Wasabi Systems Inc.?

Thursday, April 2nd, 2009

When I logged in into my blog today, a plugin called "broken-link-checker" notified me about a broken link. I wondered which link this might be, and checked it - which just increased my irritation and confusion, because it was the link to Wasabi Systems Inc. (http://www.wasabisystems.com). I checked it manually from several different hosts, and even tried to ping it - with no success. The servers really seem to be down, though the routes are still there, and the name-server still (at least at the time of this post) resolve the name into the corresponding IP-Address.

I asked around in the IRC, with the result, that I was not the only baffeld one finding the Wasabi System Inc. hosts down. According to unconfirmed rumors, Wasabi Systems Inc. is said to have closed down business some weeks ago. This is an unconfirmed rumor, and I though I have tried and searched the internet, there is absolutely no way in finding out anything reliable about the current state of Wasabi System Inc., except that their servers are shut down. When you look at the entries of the employees of Wasabi Systems Inc., which you can find on business-contact-platforms, their current employment status is "working at Wasabi System Inc. in Position <x>".

Because there is not even a page stating some kind of technical problem, and since a downtime like this would be really really expensive for a modern IT-Company, I don't believe in technical issues. On the other hand I find it really hard to believe that a promising company like Wasabi Systems Inc. should have shut down business, especially in such a mysterious, dead-silent way. Even an April's Fool's Day Joke can probably be dismissed, because while that would have been funny yesterday, today it is not. And besides that, as I said before, a Joke like this is bad publicity, and the unavailability would harm Wasabi System Inc. more than the joke would do good, because support is as unreachable as anything else.

Wasabi System Inc. was building and selling Network Storage Devices based on NetBSD and provided a journalling filesystem called wapbl, which they donated to the NetBSD community some time ago.

Here are my ping-stats:

mjoellnir@unknown:~$ ping wasabisystems.com
PING wasabisystems.com (69.9.177.46): 56 data bytes
^C
----wasabisystems.com PING Statistics----
9 packets transmitted, 0 packets received, 100.0% packet loss
mjoellnir@unknown:~$ ping support.wasabisystems.com
PING support.wasabisystems.com (69.9.177.82): 56 data bytes
^C
----support.wasabisystems.com PING Statistics----
32 packets transmitted, 0 packets received, 100.0% packet loss
mjoellnir@unknown:~$

Update:

I tried to call them, but their phone-lines are permanently "busy", no matter what time of day. As it seems, the rumours about them having closed down business are getting more and more substantial. What I wonder is, why they seem to keep it such a mystery.

Tags: , , , , , ,
Posted in BSD, NAS, SAN, Storage, hardware, internet, netbsd, network | 34 Comments »

Debian Linux / OpenSSL: predictable random number generator

Tuesday, May 13th, 2008

I just received word about a major security issue with Debian Linux' OpenSSL-Package. All Debian-Versions, from sid over lenny to etch are affected.

The issue: the openssl-package of Debian has a debian-specific change, which has caused the random number generator to be predictable. All certificates generated through these packages are thus weak and to be considered compromised. The first known affected version (0.9.8c-1) is from 2006-09-17, and was uploaded into sid at that time. It has seeped through into testing and current stable (etch). Debian Linux / Sarge, the stable branch at that time, is not affected.

Though this is relevant only for Debian Linux Systems, other systems might be affected by weak keys that have been generated on affected Debian Linux Systems.

Concerning a solution to the problem, the appropriate post on debian's security-announcement list says the following:

"For the stable distribution (etch), these problems have been fixed in version 0.9.8c-4etch3.

For the unstable distribution (sid) and the testing distribution (lenny), these problems have been fixed in version 0.9.8g-9."

An update is absolutely mandatory, as well as the generation of new keys whereever a key is in use that has been generated on an affected system.

Tags: , , , , , , , ,
Posted in Bug, Debian, Linux, OpenSSL, network, operating system, security, ssl, vulnerability | No Comments »

Smartphone-Experiments, Part 1

Sunday, March 30th, 2008

Over the last two days, I finally found a few hours to experiment with my Windows Mobile driven smartphone, an HTC Touch (ok, it's branded, so it's aka MDA Touch).

With Windows, it syncs out-of-the-box, what a surprise, but with linux, things are a bit more interesting. I am running a Debian/Lenny on my laptop, an old Acer Travelmate 732TL, a Pentium III-500 with 256MB RAM. My intention was to enable the laptop to synchronize with the phone through a USB-cable-connection, and to use the phone for internet-connections. I installed the SynCE-suite packages, along with multisync, and tried my luck. Well, what shall I say, it failed. After looking at the SynCE-manpages, I found out why: Windows Mobile smartphones require a special kernel-module to work properly. So I downloaded the module-sources from the SynCE-website, compiled and installed them, and tried again, running the following commands:

modprobe rndis_host
synce-serial-config ttyUSB0
synce-serial-start
pls

This time, it worked. I got my directory-listing. An ifconfig showed me this:

ppp0      Link encap:Point-to-Point Protocol
          inet addr:192.168.131.102  P-t-P:192.168.131.201  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:13 errors:0 dropped:0 overruns:0 frame:0
          TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3
          RX bytes:994 (994.0 B)  TX bytes:119 (119.0 B)

The two ip-addresses are the default-values of windows-mobile-phones. As far I as can tell, one should leave them as they are, since it does not seem to work with different ip-addresses (at least not for me, that is). Of course, you are free to try and comment on this ;) .

Internet-Connections

The next thing I tried now was to establish an internet-connection through the smartphone. From the phone's manual I knew there was a program for a shared internet-connection, where the telephone connected itself into the internet by using GPRS/EDGE, and acted as a router/nameserver for the connected computer. I activated that program from the programs-folder (in german, this program is called "Internetfreigabe"), selected "USB" for the connection to the computer, and the GPRS-profile, and then let the program connect to the internet. Though the telephone complained about ActiveSync being "active", it connected me to the internet. An ifconfig gave me now this output:

rndis0    Link encap:Ethernet  HWaddr 80:00:60:0f:e8:00
          inet addr:192.168.0.102  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::8200:60ff:fe0f:e800/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:8050  Metric:1
          RX packets:59 errors:53 dropped:0 overruns:0 frame:0
          TX packets:102 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:6848 (6.6 KiB)  TX bytes:19488 (19.0 KiB)

I tried to ping my server using its ip the first time, and its name the second, and both worked fine: I was connected. However, further experiments showed that simply connecting the phone and loading the modules, and then activating the internet-connection on the phone would not work. And rndis0-interface would show up, yes, but it will look like this:

rndis0    Link encap:Ethernet  HWaddr 80:00:60:0f:e8:00
          inet addr:169.254.2.2  Bcast:169.254.2.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:8050  Metric:1
          RX packets:12 errors:9 dropped:0 overruns:0 frame:0
          TX packets:48 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1124 (1.0 KiB)  TX bytes:7168 (7.0 KiB)

Take a good look at the ip-address, you will notice that it is different from the first two ifconfig-dumps, which used the same ip-adress. A connection will not be possible this way, it has to be set-up and established through synce-serial-config and synce-serial-start before.

Though I have installed Evolution, multisync, and several plugins/modules for both programs, I was not yet able to synchronize my telephone's address-book, calender, todo-list etc. with the laptop. May be Debian/lenny uses packages which are not as up-to-date as I would need it, I have take a further look into this, still. The most important two things, anyhow, being able to transfer files between telephone and laptop, as well as establishing an internet-connection for the laptop by using the telephone as a router/modem, are working now, and quite without an effort, too.

I will continue with my smartphone-experiments, so stay tuned! ;)

Tags: , , , , , , , , , , , , ,
Posted in Linux, computer, connection, experiments, gadgets, internet, mda, mobile, network, smartphone, smartphone-experiments, synce, synchronization, touch, windows | 1 Comment »

Tech-blog opened

Thursday, March 13th, 2008

Welcome to this blog. It is dedicated to computer-technologies with focus on programming, opensource-topics, operating systems, it-security, embedded gadgets like smartphones, etc.  You can read more about this on the about-page.

Stay tuned.

Tags: , , , , , , ,
Posted in computer, gadgets, network, operating system, programming, security, smartphone, tech | No Comments »