monline

I've found three apps that are worth to mention:

• tPacketCapture: works only on Android v4.0+, but requires no root access (and captures only TCP/UDP, but that's sufficient for most use cases)
• Shark for Root: seems to be the most popular choice, but hasn't been updated for the last 1.5 years (requires root access and is a frontend for tcpdump)
• Packet Sniffer: this one is quite similiar in features to Shark (hasn't been updated for years, requires root and is a frontend for tcpdump)
• SimplePacketCapture: a very basic UI, requires root access (probably a frontend for tcpdump, but the app's description does not say so)

The poster of this Apple Discussions topic experienced interference from Internet Sharing while he tried to use Web Sharing. I had it the other way around: my Internet Sharing failed to work because of Web Sharing. I use the latter for some web development and testing (mainly PHP) and today I tried to set up Internet Sharing (I wanted to share my wired connection through Wi-Fi with my mobile phone). The symptoms were these: the phone could successfully connect to the Mac's Wi-Fi network, got an IP and could even access the Apache webserver that was running on the Mac. However it could not access internet sites. Once I stopped Web Sharing, the phone could access the internet just fine. The conclusion: Internet Sharing and Web Sharing cannot work simultaneously in Mac OS X Leopard.

Using a torrent client with lots of connections my (Snow) Leopard used to get stalled (it just hangs and no app seems to be responding, but the GUI remains mostly functional though). The solution seems to be a bit of a network tweaking.

A "protocol relative URL" is an absolute URL without the starting scheme + ":" part. Eg. a protocol relative URL of http://google.com/ is //google.com/. You can read all about various sorts of URL references in RFC 3986 ("Uniform Resource Identifier (URI): Generic Syntax"). Unfortunately not all web clients support protocol relative URLs (eg. various IE versions exhibit different problems and Safari in some iOS versions breaks too). You can read some notes and comments on this at Paul Irish's blog or in this post at Wikimedia's blog.

"Microsoft Network Monitor is a packet analyzer. It enables capturing, viewing, and analyzing network data and deciphering network protocols. It can be used to troubleshoot network problems and applications on the network."

The de facto standard for network capture and analysis is Wireshark, but Microsoft also developed their solution for the problem and named it simply Network Monitor. The app has no real homepage, only a small knowledge base article. Most of the available information is gathered on Wikipedia and the app's blog.

Just found out that the reason for the hangs I've been experiencing (for ages) is a 7 year old bug in Firefox. It's even documented in the main "Firefox hangs" Mozilla KB article. Since my PAC file was not too complicated, I can easily live without it. But people seriously depending on a PAC are screwed.

The page describes SYN cookies pretty well. For a bit more info, take a look at these:

• SYN cookies at Wikipedia
• TCP variables in the Ipsysctl tutorial
• Linux firewall-related /proc entries

Up til now I believed that all Oracle database connections are firewall-crippled by the well known SQLNET setup: client connects to server's 1521 TCP port (the TNS Listener), the server starts a DB process to handle the connection and tells the client to disconnect from TNS Listener and connect to a newly opened, random port. Ie. you've to open all ports on the server for traffic coming from the client. However today I've monitored with Wireshark a connection being estabilished through an SSH tunnel from an Oracle client (running PL/SQL Developer) to a 9iR2 database server and only a single connection was used the whole time!

Is this really a bug in the VPN client? All operating systems have components that run at the highest possible privilege level (see: privileges in protected mode). Thus at least "some" code can have access to all memory segments, so we can assume that the process memory is not protected (well enough). However the VPN client is going to need those passwords in clear text at some point. And if we assume that a malicious user runs a debugger eg. in the kernel and steps through the code of the VPN client and watches the memory closely, the passwords cannot be fully protected. Of course having the passwords in the memory in clear text for the shortest possible period can help make life more difficult for prying eyes, but not "that much" more difficult.