WRVS4400N IPS causes tomtom map download to fail

[peter.pircher]

The latest tomtom go live 1005 car navigatioin device map updates on http://download.tomtom.com/nav3/865/nav3/Europe.ttpkg fails after 80% (over 2 GB of data downloaded) with a timeout.

After disabling the IPS for http the download works.

Just in case someone else has a similar issue (I also posted on the tomtom forum pages).

Peter

[claudio.venturini]

Hi,

I've a similar problem, not with WRVS4400N but with the router RVS4000 (firmware v1.3.2.0). AFAIK they employ the same IPS system.

I have a new TomTom GO500, and the dowload always blocks after having downloaded approximately 55MB (out of 270MB). I noticed that the IPS blocked the connection with this report:

2014-02-18 23:26:15

CHAT ICQ2003b message

217.212.225.64

It seems that the IPS recognize the connection as an ICQ session, but it's not. Why the IPS blocks the connection?

Then I disabled IPS for ICQ, and the download passed the 55MB barrier, but still didn't complete. It blocked after 225MB (79%). This time, the IPS blocked the connection with this trace:

2014-02-18 23:38:04

CHAT QQ&TM Login attempt via TCP -3

2.16.219.81

I tried again, and the IPS blocked the download after only 4MB, with the same trace.

So I disabled the IPS also for IM_QQ. This allowed me to complete the complete the download.

I think that the problem is in the IPS signature (my signature version is 1.50).

Dear Cisco, can you fix it?

Thank you!

This is a dump of the HTTP request, traced with CURL:

== Info: About to connect() to download.tomtom.com port 80 (#0)

== Info:   Trying 77.67.96.222... == Info: connected

=> Send header, 241 bytes (0xf1)

0000: GET /sweet/navcore/00000000-0111-0013-0400-014817502059_system-u

0040: pdate.ttpkg HTTP/1.1

0056: User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 Ope

0096: nSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3

00c7: Host: download.tomtom.com

00e2: Accept: */*

00ef:

<= Recv header, 17 bytes (0x11)

0000: HTTP/1.1 200 OK

<= Recv header, 16 bytes (0x10)

0000: Server: Apache

<= Recv header, 53 bytes (0x35)

0000: ETag: "3879fd1067cfbce365d4632cc9413f87:1392250601"

<= Recv header, 46 bytes (0x2e)

0000: Last-Modified: Wed, 12 Feb 2014 10:18:19 GMT

<= Recv header, 22 bytes (0x16)

0000: Accept-Ranges: bytes

<= Recv header, 26 bytes (0x1a)

0000: Content-Type: text/plain

<= Recv header, 27 bytes (0x1b)

0000: Content-Length: 284123402

<= Recv header, 37 bytes (0x25)

0000: Date: Tue, 18 Feb 2014 23:05:14 GMT

<= Recv header, 24 bytes (0x18)

0000: Connection: keep-alive

<= Recv header, 2 bytes (0x2)

0000:

... and then start receiving data

[claudio.venturini]

I noticed that the TomTom server respond with the header "Content-Type: text/plain", but the downloaded file is a binary file, so it should be "Content-Type: application/octet-stream". Could this have an influence on how the IPS behaves?

If so, maybe the solution could be to ask TomTom to ensure the respond with the correct header.

[mpyhala]

Claudio,

I think that it is unlikely that Cisco will release any new IPS signatures or firmware updates for the WRVS4400N unless there is a major security issue since it is End-of-Life:

http://www.cisco.com/c/en/us/products/collateral/routers/wrvs4400n-wireless-n-gigabit-security-router-vpn-v2-0/end_of_life_notice_c51-714313.pdf

- Marty

[claudio.venturini]

I thought Cisco would have not fixed the IPS signatures for and end-of-life router. Anyway, I think that for Cisco is important to know about this issue, for example to test if it also affects any other router not end-of-life.

Thank you anyway!