What are you looking at?

Filed under: — Posted on 2004.07.30 @ 12:22

The NYT reported yesterday that two Columbia University scientists figured are using computers to extract images of what a person was looking at from reflections on the cornea. The article has pictures of the technique.

SYN, SYN-ACK, RST brain

Filed under: — Posted on 2004.07.28 @ 22:13

Despite my triumph earlier in the day in discovering a duplex mismatch that was overlooked, I also spent far to much time thinking about another problem in which I forgot my basic IP handshaking and routing fundamentals.

We’re migrating to a new ISP, so in a flash of brilliance I figured I’d setup another interface on the PIX to test the new connection. The connection appeared to be up, since I could see the flood of Windows zombies attempting to connect already. But I was unable to actually pass any data over the link.

After poking around the logs I determined that the firewall was not blocking anything, nor was iptables on the web server. I plugged in a hub between the web server any the firewall, and ran ethereal on my notebook to see what was happening. What I saw was the handshaking failing on the link. SYN packets would come in from my external host, and the server would send the SYN-ACK back. The external host would then reset the link with an RST.


Routing error causes RST packets.

I thought about it for a bit before realizing my downfall: the web server is NAT’d behind the firewall. The external host was sending to one address, but the firewall was sending the reply on a different address. The external host thinks “spoof” and resets the connection.

A failed auto-negotiation

Filed under: — Posted on @ 21:25

We have been receiving complaints of slow printing services on and off for the last couple of months at the centre, but had been unable to nail down any problems. Endless combing through documentation and reviews of the settings turned up nothing. Today I happened to recognized the problem while doing some other network configuration work.

It turns out the server that handles the print queues had its interface locked at 100Mbs full-duplex. The switch was set to auto-negotiate, resulting in it setting the connection at half-duplex. This is a recipe for exactly the kinds of problems we were experiencing - poor performance under load. Once the server was configured to auto-negotiate the link (since it will be moving to a new switch soon), printing performance drastically improved. Printing a PDF with graphics that took several minutes at times now prints in seconds.

This quote excerpt from Critical Networks Advanced Ethernet pages explains netter than I could how the duplex mismatch occurs:

So how does a duplex mis-match occur? The process below describes just one common scenario where one device is auto-negotiating but the other device is hard coded for full duplex:

  1. The hard coded device is configured for 100baseTX full duplex (100FD) operation. It does not listen for FLPs sent by the other device, it simply waits for the correct idle signal before making the link active
  2. The auto-negotiating device will notice the absence of FLPs and will see the 100baseTX idle signal using parallel detection. It will make the link active as 100baseTX half duplex (100HD).
  3. Now link is active on both devices and data will be transmitted, but there will be performance problems
  4. The hard coded 100FD device can send data at any time regardless of whether the 100HD device is transmitting. This causes the 100HD to detect both excess and late collisions and to abort the current frame in mid-transmission. This in turn causes the 100FD device to see many runts, alignment, CRC and FCS errors.

MS word annoyance

Filed under: — Posted on 2004.07.27 @ 11:28

I’m filling out a reference form for a vendor of ours that was provided by another client, and am frustrated as hell by MS Word’s insistance that it knows better than I when I want to capitalize a word at the beginning of a line. Turning off auto-correct capitalization has no effect, nor does disabling the grammar checking for capitalization.

That one simple little “feature” is one of the first things I disable on any computer I use, since I often type in code or configuration information that I don’t want capitalized. It’s is endlessly annoying that Word insists on automatically fixing something that I want left alone!

… I eventually found the option, after having to manually edit several more lines. The’re using tables in this document, and there’s a different option to disable capitalizing the first character of a table cell.

Reverse firewalls?

Filed under: — Posted on 2004.07.21 @ 10:19

In a recent article, Phillip Hallam-Baker, Principal Scientist at Verisign suggests reverse firewalls ought to be built into cable modems and home use WAPs. The idea is to filter outbound traffic before it leaves the source instead of letting it travel to its destination before being filtered.

Perhaps filtering might better be done at the ISP first, since it’s probably more cost effective to implement and manage a solution there than it is to replace cable modems. Vendors of small DSL/Cable routers should have outbound filtering as a default. The current norm is minimal filtering and security on by default to make it simple for users to install.

The idea works; many companies already employ this type of filtering on their corporate LANs (we only allow SMTP connections from the mail servers).

Junk mail filtering

Filed under: — Posted on 2004.07.20 @ 21:31

I setup junk mail filters at work last week, and they seem to be doing the trick. So far I’ve received no complaints of missing mail or blocked mail. We’re rejecting 28% of attempted deliveries, and have tagged 35% of the mail that passes the initial tests as spam. All told, 53% of all mail coming into the centre is unwanted, and blocked or marked as such.

When network changes aren’t smooth

Filed under: — Posted on @ 19:38

We forklift upgraded the two main wiring closets in the hospital on the weekend. As expected, there were some problems with workstations not connecting properly or having their connection speed throttled. At the end of the day yesterday a couple of techs finally resolved a problem with a station failing to connect to the network.

A few minutes later the network became completely unusable. Of course we were foolish and didn’t immediately go to the last change made, and spent the next three hours going through our normal diagnosis. Similar problems have occured in the past when worm-infected laptops were connected to the LAN. In the end, we went back to the prior changes, and disconnected the now-working node. Lo and behold, the problems went away immediately.

The experience was good for us. I recall one of Pournelle’s Laws is something to the effect of: always start with the cables, because you’ll end up there. But the time spent hunting wasn’t wasted because we discovered some other traffic to be inspected while running Ethereal.

LawGeek: DMCA hammer comes down on tech service vendor

Filed under: — Posted on 2004.07.12 @ 10:49

LawGeek commented on Friday about a preliminary injunction being granted to StorageTek, who are seeking to block third party service of their products with claims it violates the DMCA. Logically, and I’m sure legally, the judge is correct to issue the injunction. The concern is where this leads. Companies have tried using the DMCA before but haven’t been completely successful.

Slashdot picked up the story this morning, and the usual comments followed. One of the first questions raised is when car manufacturers will figure out how they can block third party service on vehicles. I’m sure they’ll figure out a way soon enough, and as soon as they do, the DMCA will be overhauled.

Offline for a bit

Filed under: — Posted on 2004.07.10 @ 22:05

A new family member has my attention.

Creative Commons License
This work is licensed under a Creative Commons License.
Powered by WordPress