8.8.10
I just had a moment of contentment for being able to copy files using UNC paths across the Internet between different sites. This is thanks to having spent too many hours figuring out limitations and quirks in the routers, access points, firewalls and servers in the picture. Last night I finally moved all IPv4 traffic to my new DMVPN tunnels.
As a result I have realized what the minimum IT hardware requirements are for comfortable living. (more…)
6.6.10
I just patched a couple of ESXi hosts to 4.0.0 build 256968 and found that VMware Tools were no longer loading after upgrading them. After some digging everything is more or less back to normal. (more…)
13.6.09
Ekiga has a problem talking from behind a firewall, or maybe the problem is that both the firewall and Ekiga are trying to be too clever. I’m running siproxd on the firewall to transparently handle SIP connections. All the hardware phones and ATAs as well as X-Lite work well, but Ekiga fails to register.
The fix is controversial: I’m disabling STUN.
gconftool-2 -s /apps/ekiga/general/nat/stun_server --type=string
However, this means Ekiga won’t work from less “intelligent” networks anymore. Since I’m considering Ekiga for my laptop, this might be a problem. Maybe I should try X-Lite under Wine.
2.6.09
I’ve been observing a really strange problem on Ubuntu Server 8.04: processes are sitting in limbo not doing anything. I first observed this as phones losing their SIP registrations periodically (but at random intervals).
When debugging the issue, I saw that a ping running on the system would often just sit there, not sending more packets, sometimes for seconds on end (I didn’t always wait to see if it would ever continue). Since hitting a key on the keyboard would immediately be echoed back, it wasn’t a problem with the terminal or ssh connection. Pinging the system from another would work without problems. Interrupting ping would report no packet loss (which was true — you can’t lose replies to packets you didn’t send).
My best guess is that the alternative scheduler chosen by the Ubuntu developers for the server kernels doesn’t work as intended on AMD CPUs (or just the Athlon XP, or some other part of the hardware I’m using).
My “fix” was to switch to Debian 5.0 (lenny), which doesn’t exhibit this problem at all.
I could have tried with the desktop edition of Ubuntu, but can’t really spare the time right now. Especially since I now have something that works reliably again.
I did try with different network hardware, though. I was originally using an SMC card based on ns83820 (but for some reason not reporting anything at all with ethtool — works fine with the gsip driver on NetBSD). I then switched to a Netwjork “brand” card based on r8169 (well liked by ethtool). No difference, but stayed with the latter (working ethtool is always nice).
24.5.09
Just a short note on getting a minimal Asterisk environment installed on current versions of Debian and Ubuntu:
aptitude install asterisk
m-a a-i zaptel
modprobe ztdummy
Also add ztdummy to /etc/modules so it gets loaded when the system starts.
If the m-a command is not found, install the module-assistant package.