I have the newest 2.0 final code, as well as the newest Hijack release. This has been going on for some time. Only occasionally will the khttp webserver work. Other times it will work for a while, and then stop responding.

I get no errors via the serial port, even when I try to access a page that does not exist, whereas when I do that when it is working I will see an error in the shell.

when it is doing this I can still connect via emplode, or ftp.

then after a while of not working, it will begin to work again.

Are there any log files I can check, or any debugging to turn on to find out why http doesn't alwas work?

I'm thinking this could be related to my sync's just hanging when doing large transfers.

Try turning off "keep alive" and/or "pipelining" in your web browser configuration. It is probably keeping the connection open after each request (not supported by Hijack's khttpd), and web server (by default) only supports a max of 4 connections.

-ml

Is that default configurable?

Yup, it's in the FAQ.

But if his web browser really is guilty of trying to keep the connections open after each request, then upping the number won't fix it.

The Hijack web server specifically tells the browser to CLOSE the connection after each response.

But then, I'm only guessing what's going on there. Works for me.

Cheers

Greetings!

I know there is some strangeness with KeepAlives and the server sending a close signal. Q811383. I know this one without looking it up because it has bitten me on a number of occasions.

As to changing the number of threads being in the FAQ, I had just checked that before I posted. I missed it. Sorry about that. <stands in corner with dunce cap on>

well here's the weird thing, I can understand the keep alives thing, (but for the life of me couldn't find it in IE, I know, I know)

but I keep my empeg at work, I came in today on tuesday, last time I used my empeg was on Thursday last week, it's been unplugged and in my desk all weekend.

I plugged in the ethernet cable, then put on the power, it booted up. I tried connecting to the webserver......... no luck. This is what usually happens, it never seems to work when just coming up, or anything, there's really no pattern as to when it starts working, and when it doesn't work.

any sort of debug levels to turn on? logging? etc?

thanks

Check the "about" menu on the empeg and see if it has successfully negotiated DHCP to obtain an IP address.

OR even better, hardcode an IP address (aka "static IP") using Emplode. Whenever I have network trouble with my empegs, it's ALWAYS the failure to complete DHCP negotiations. They just don't seem to like my DHCP server most of the time. Which is weird, cuz everything else on the network (14 machines) has no problems with DHCP.

Cheers

Whenever I have network trouble with my empegs, it's ALWAYS the failure to complete DHCP negotiations. They just don't seem to like my DHCP server most of the time.

You've mentioned this a number of times. I've never seen that happen. I don't doubt your results, though.

Is it possible that it takes your switch a long time to fall back to 10Mbps/half duplex? I had a similar problem once (although it had to do with STP reconfigs and not ethernet negotiation).

Check for dodgy ethernet cabling. Replace the one between your empeg & the router/hub and see if things improve.

-Zeke

I'm not sure what it is, but I got the same misbehaviour when everything was connected via hubs instead of the newer 16-way switch.

Just for kicks, I have one of those $5 router/gateway boxes here, with a built-in DHCP server. I'm going to plug that into the switch and see if the empegs are any happier. If it works, then perhaps a software upgrade to the latest DHCPD sources may help.

Cheers

Thanks for the ideas, but here at work, I plugged in a Static IP. and even when web server is not working, emplode and ftp can connect with no problems whatsoever. then a little while after being booted up, web server works. then stops working. throw that in a while (1) loop just for fun, and you've got the behaviour of my web server.

Try a different web browser then. Specifically, try mozilla

how frustrating, Mozilla suffered the same fate as IE.

doing a

ping -U -p 80 [ip_address]

it does respond and say it's alive. however I still cannot connect to the webserver. again, this was just after turning it on, within 10 minutes anyways.

ftp just verified as working, however web server still is not responding.....hmmmmmm so strange.

any way to turn on any logging? network sniffers perhaps my next option?

Do you have one of the IIS exploit viruses, like Nimda or Code Red, running on your networks? Those could easily fill up the maximum of four connections to the empeg web server with their constant pounding of HTTP requests.

Being on the work network, those would be sniped out pretty quickly if they were on. I see no requests or anything via the empeg shell connection. when the webserver is responding, then I can request a non-existent page and receive an error via the shell. when it's not responding, I get nothing. So strange, I'm gonna try a sniffer to see if the empeg responds at all.

Stay tuned for the excitement.

Uh. Not sure what version of ping you've got but the -p option is used to set a pattern for the ICMP packet. It's not to specify what TCP port. Ping is only for ICMP packets.

Use "telnet [ip_address] 80" to see if you can connect.

- Trevor

Hook up the serial port so you can see what's going on (standard Empeg debug procedure). And modify your config.ini to include this:

    [hijack]

    kftpd_verbose=1

    khttpd_verbose=1 ;;2 also works, but much more data..

This causes all new connections to be logged on the serial link.

It's the version of Ping with Solaris 8. The -p specifies the port and is used in conjunction with the -U option to specify it to transmit UDP packets.

I'll turn on the debug options and monitor the shell, like I said I got nothing previously, but that was before the config.ini edit. I'll post if I receive any information.

Ahh okay. I never knew you could tell it to send UDP packets. I've never actually read the man page for ping on a recent Solaris
It's still a good idea to see if you can telnet to port 80 directly however as khttpd uses TCP.

- Trevor

well crap, wall after wall after wall. Turned on the debugging, and when it doesn't work, I get a big fat nothing in the shell, even tried putting the level to 2.

when it wasn't working, tried telnetting to port 80 and it worked fine.

I'm at a loss, perhaps it's something screwy on the work network, but since everything else works fine, you would think the route to the empeg is fine. not sure what to look at now, it's listed as a trusted site in IE. and netscape didn't work either when the webserver wasn't responding.

gonna have to try putting it on my home network and see if I still get the same issues. if so I'll start up a network sniffer and see what's going on exactly. thanks for all the help so far.

I assume you are using the direct IP address, rather than a hostname, when it fails.. right? If not..

yep, direct IP for all access to the empeg, emplode, jemplode, ftp, and web.

Well, I now have a case that I can easily prove isn't this: I can telnet and ftp to the player, and *just* not connect to the web server. I'm going to leave it up and play with it tomorrow, though, because I think I've reached the end of my day.

Yeah, this is neat. If I watch the console:
hijack: removed menu entry: "Serial Port Assignment"
khttpd: listening on port 80
kftpd: listening on port 21

But, according to nmap (range 1-65535)
Initiating SYN Stealth Scan against 10.254.0.4 at 00:30
Adding open port 21/tcp
Adding open port 8301/tcp
Adding open port 8300/tcp
Adding open port 23/tcp

and none others. khttpd_verbose=1 is useless, of course. I still don't know what the problem is. It stopped working in v340 (it may have worked for a while before stopping) and updating to v344 changed nothing. I have no idea, at this point. I'm about to start looking at code now.

From the "beats the heck out of me" department:
flashed 340 on it. it worked. flashed the same 344 image I had on before back on. it worked.

I have no idea. I'll pretend it never happened and find something else to waste my time on