Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

This is a bit of a specialist question as it concerns a very small embedded web server as opposed to a conventional web server (e.g. Apache, IIS) and it's more to do with the routing through the ISP.

I am the programmer responsible for implementing an embedded web server inside a hardware product. This is basically a consumer device that sits in a customer premises. The customer can optionally use the internal web server to perform configuration, and obviously they can port forward through their router if they want to so that they can access it from outside over the Internet.

I am trying to investigate a bizarre situation where a device installed at a particular premises is responding to requests for .htm and .cgi files absolutely fine, and it will also respond with a 404 as it should do when a nonexistent file is requested. However, if a .png, .jpg, .css, or .js (and no doubt many others) is requested, then what happens is the HTTP request hangs indefinitely and eventually times out. At this point, the browser just displays what it was able to load after that time, which is typically just the raw HTML without any of its image, style or script resources. (I'm seeing all this using the 'net' tab in Firebug.)

All I know about the device on the premises is that it's sat in a house which apparently uses the Virgin Media ISP, behind a pretty standard household modem / router. Unfortunately I'm unable to find out any more than that at the moment, and I can't physically get to it myself.

The HTTP server is presently configured for port 80.

The installer informs me that access to the HTTP server is absolutely fine when accessed at the premises locally; that is, all images and so forth load without issue. Furthermore, I've never, ever come across an issue like this with the product before. Stranger still is the fact that a previous product of ours installed there had pretty much the same web server inside - and didn't have this issue at all. So I've no idea if this could be conincidence or not.

Is there any possibility at all that the ISP could be applying filtering or otherwise somehow fiddling with incoming HTTP requests? At the moment this is the only straw I have to clutch at.

The web server in use is the HTTP server that is supplied as part of the Keil MDK-ARM library. The product is basically a small bit of custom hardware with an ARM processor, running a lightweight Keil RTOS that is also part of MDK-ARM. I don't believe that there is anything relevant I can state about the actual function of the box.

EDIT: Additional Wireshark clue

I've been taking Wireshark logs when I've attempted to just directly request a 'problem' file type, e.g. one of the .css or .js files. What I have found is this:

Rather than seeing a stream of one or more TCP packets that together form a valid HTTP response, aside from the usual ACK packets I instead only see a single TCP packet containing what is presumed to be part of the HTTP response. Wireshark marks this packet as "Continuation or non-HTTP traffic [Malformed packet]" because, due to lack of HTTP header in the packet, it can't tell what it is.

On further inspection I realise that these single 'malformed' packets I get whenever I request a problem filetype actually contain a payload of just four bytes of the actual requested HTTP file. For example, the packet's four-byte payload might be ID=b, which corresponds with ID=blahblah at the start of the .js file I had requested. (I made that particular example up, but this is the consistent behaviour I'm seeing when requesting .css and .js files).

So, in short, intead of getting back a complete HTTP response within one or more TCP packets and including a HTTP header, instead I'm just getting back a single packet with a payload of just four bytes that I know are four bytes of the original file being requested.

Edit 2: Further to the above, I've realised that any image that is very small in terms of bytes (say less than 1K) is successfully served back. It's almost as if it's okay as long as the response will fit into one TCP packet. Any larger than that, and the bizarre issue described above happens. But for .htm or .cgi, the response can be as large as it likes and it works.

share|improve this question
    
To be clear: This only happens when accessing the device from outside the residence? –  Michael Hampton Feb 21 '13 at 9:44
    
@MichaelHampton That's correct. The installer tells me that when accessed internally, all behaves fine. Unfortunately I don't know if this is via a direct Ethernet connection from device to laptop, or if this still happens via the router - but I could give him a ring to find out. –  Trevor Page Feb 21 '13 at 9:46
    
And is there any good reason why you don't want to say what the embedded device is? This might be important information. –  Michael Hampton Feb 21 '13 at 9:47
    
It's probably best that I'm not specific about the product itself, but I think the only relevant thing to state is the actual embedded HTTP server being used. I'll put that in the question. –  Trevor Page Feb 21 '13 at 9:50
    
Does the embedded web server have any accessible logs at all? Otherwise, could you put a device to snoop the traffic to it to trace whether those requests actually ever get to the web server or not? –  Jenny D Feb 21 '13 at 10:01
show 4 more comments

1 Answer 1

Yes, it's possible, but unlikely that they're doing it in this way.

(Make sure that nothing else is b0rked before you ring up the ISP. Might be as well a wrong MIME type of a resource that has something between your server and client (or even the latter) choking on it).

share|improve this answer
    
many thanks. That is certainly an interesting possibility. I've just added some extra information about how Wireshark seems to indicate the responses are being mangled very strangely. –  Trevor Page Feb 21 '13 at 12:07
    
Yes, from the way it looks, there is something in between who does something with your HTTP traffic it's not supposed to do (since you're getting good answers in the internal network). –  Roman Feb 21 '13 at 12:10
    
It would seem that the mangling seems to be done on anything that isn't text/html, OR otherwise it won't be manged as long as it fits within a single TCP packet. –  Trevor Page Feb 21 '13 at 12:43
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.