Showing results for 
Search instead for 
Did you mean: 

Downloading from Apple Mountain Lion App Store Hangs 2901 router



I have a repating 2901 router failure when people attempt to download Apple Mac OS X Moutnain Lion upgrade from App Store.

The 2901 just hangs following getting a series of ZBFW packet drop failures:

001928: Jul 26 22:37:18.783 UTC: %APPFW-4-HTTP_PROTOCOL_VIOLATION: HTTP protocol violation (0) detected - session on zone-pair ZP-PRIVATE-OUT class ccp-protocol-http appl-class ccp-http-blockparam

001929: Jul 26 22:37:20.871 UTC: %APPFW-4-HTTP_DEOBFUSCATION: Deobfuscation signature (15) detected - session on zone-pair ZP-PRIVATE-OUT class ccp-protocol-http appl-class ccp-http-blockparam

001930: Jul 26 22:37:22.779 UTC: %FW-6-DROP_PKT: Dropping tcp session on zone-pair ZP-PRIVATE-OUT class ccp-insp-traffic due to  Stray Segment with ip ident 0

The failure results in the ACT Light stopping to blink and the SYS Light remains on solid Green and the entire router hangs.

I cannot SSH to it, all logging to console stops and the only way I can recover the router is by powering it off and on again.

This is very alarming as this is a very common download site and I am finding router is hanging consistently and repeatly when people go there.

Does anyone have any suggestions?

This looks like a major bug in IOS.



1 Accepted Solution

Accepted Solutions

I had a similar issue with a 2811 router and IDS. Transfers would start fine but would eventually slow down to a crawl. I ended up upgrading to a 15.x IOS version and adding the ooo global parameter map to increase the reassembly buffers. I think that's what ended up fixing it in the end.

parameter-map type ooo global

  tcp reassembly queue length 512

  tcp reassembly momory limit 16384

Hope it helps.

View solution in original post

9 Replies 9



as suspected this appears to be a problem with ZBFW.

As a work around I have moved HTTP inspection down to the end of my policy list, so TCP protocol policy take priority of HTTP application policy and now people can download again.

So the work around for the time being appears to be to disable HTTP inspection.

I am very surprised that I appear to be the first person who has reported a problem here, as this is a major web site that is having a problem with HTTP inspection.

I hope that cisco responds with a patch or particular configuration resolution.