> traceroute -m 100 216.81.59.173
traceroute: Warning: Multiple interfaces found; using x.x.x.x @ net0
traceroute to 216.81.59.173 (216.81.59.173), 30 hops max, 40 byte packets
. . .
8 10gigabitethernet1-2.core1.atl1.he.net (184.105.213.110) 122.807 ms 150.309 ms 168.517 ms
9 216.66.0.26 (216.66.0.26) 160.820 ms 164.675 ms 157.556 ms
10 * * *
11 Episode.IV (206.214.251.1) 188.004 ms 188.078 ms 277.575 ms
12 A.NEW.HOPE (206.214.251.6) 212.980 ms 182.796 ms 217.315 ms
13 It.is.a.period.of.civil.war (206.214.251.9) 208.230 ms 231.501 ms 187.249 ms
14 Rebel.spaceships (206.214.251.14) 223.330 ms 185.769 ms 231.825 ms
15 striking.from.a.hidden.base (206.214.251.17) 222.702 ms 199.810 ms 227.345 ms
16 have.won.their.first.victory (206.214.251.22) 186.517 ms 221.058 ms 201.745 ms
17 against.the.evil.Galactic.Empire (206.214.251.25) 185.988 ms 216.445 ms 186.553 ms
[read more...]
Update: fixed in v19.0beta (at least v19.0b1 build3 looks good):
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/ (19b1 does not save sessions, though ;-)
Firefox 18 (all betas and 18.0) crashes on Solaris 11 and OpenSolaris. The workaround is to set the following variables to "false":
browser.cache.disk.enable
browser.cache.memory.enable
browser.cache.disk_cache_ssl
See bug 827971.
Sometimes you do not need a detailed log-analysis but several simple one-liners that you can adjust without too much thinking how it works, what you did last time, etc. The examples below are absolutely NOT optimal, but rather modular for easy line-editing.
And that means that the design is broken again. Anyway, playing with various stuff – this is what this site is made for ;-)
If UPnP devices do not see each other, most likely there are two problems:
Multicasts are not forwarded
Simple Service Discovery Protocol (SSDP) uses multicast IPv4 address 239.255.255.250. The local switches must be able to forward such traffic. On a Cisco switch you run the following command to allow that:
Firewall blocks UPnP traffic
Related ports: UDP-1900 and TCP-2869
Solaris 11: root/solaris
Cyclades console servers (e.g. ACS4): root/tslinux
Avocent ACS5000 console servers: root/avocent
Avocent ACS6000 console servers: admin/avocent or root/linux
Cisco VPN3000: admin/admin
Cisco ASA: empty
Netscreen: netscreen/netscreen
Avocent/Cyclades PM IPDU: admin/pm8 root/linux
Solaris 11 EA (Sep 2011 build 173) updated zpool version to 33:
$ zpool upgrade -v
This system is currently running ZFS pool version 33.
The following versions are supported:
VER DESCRIPTION
— ——————————————————–
1 Initial ZFS version
2 Ditto blocks (replicated metadata)
3 Hot spares and double parity RAID-Z
4 zpool history
5 Compression using the gzip algorithm
6 bootfs pool property
7 Separate intent log devices
8 Delegated administration
9 refquota and refreservation properties
10 Cache devices
11 Improved scrub performance
12 Snapshot properties
13 snapused property
14 passthrough-x aclinherit
15 user/group space accounting
16 stmf property support
17 Triple-parity RAID-Z
18 Snapshot user holds
19 Log device removal
20 Compression using zle (zero-length encoding)
21 Deduplication
22 Received properties (Solaris Nevada b130 Dec 2009)
23 Slim ZIL
24 System attributes
25 Improved scrub stats
26 Improved snapshot deletion performance
27 Improved snapshot creation performance
28 Multiple vdev replacements (ZFS for Linux)
29 RAID-Z/mirror hybrid allocator
30 Encryption
31 Improved 'zfs list' performance (Solaris 11 Express b151a Nov 2010)
32 One MB blocksize
33 Improved share support (Solaris 11 EA b173 Sep 2011)
Recently I've stumbled upon a strange looking site-to-site (CheckPoint R70 to Cisco VPN3k) VPN problem:
Connections from some networks were dropped with the following error:
Encryption failure: Received a cleartext packet within an encrypted connection
The first step was to check the encryption domains for the tunnel. In both GUI and /etc/fw/conf/user.def the encryption domain was the whole class B network, assigned to the company.
Next step was tracing.
Blog updates