Hijack v124: kftpd & khttpd stuff

Okay v124 is out.

Recent stuff of interest includes the new kftpd "SITE" commands:

-- SITE RO
-- SITE RW
-- SITE REBOOT
-- SITE EXEC arbitrary command ; another arbitrary command

The RW command remounts /,/drive0,drive1 for read-write access, and RO puts them back into read-only. Wait about 5 seconds after issuing them, because they execute asynchronously.

None of the SITE commands return any output, and none of them return any status codes other than "Okay". That's because I gave up trying to figure out how to communicate with the child spawned from the internal execve() invocation (slightly different from usermode). All stdin/stdout/stderr for any such commands is simply redirected to the serial port for now. But the mechanism works, crude as it may be.

Also new, is the /proc/empeg_kernel "device", created within the kernel by Hijack. This is simply a block device entry for MAJOR=60 MINOR=8, the "kernel" flasher. If you use FTP to upload a kernel zImage file to /proc/empeg_kernel then it will be burned to flash during the FTP. Takes about 5 seconds.

This is the much faster equivalent to using "download" or "logo editor" to flash a new kernel. Works fine on a stock consumer image, too, so long as Hijack v124 (or higher) has been installed.

Also recently new, is the ability to write to /proc/empeg_notify. Reading from it just gives the player status (requires [output]notify=1 in config.ini), but the other direction can be used to inject commands to Hijack:

echo "button 20df12" >/proc/empeg_notify (a short press)
echo "button 20df12.L" >/proc/empeg_notify (a long press)

This virtual button pressing can be done remotely using FTP to write to those files, as well as using the FTP SITE EXEC command to issue those "echo" commands shown above.

In addition to "button" commands, one can also do"

echo "reboot" >/proc/empeg_notify

and also for fun you can do:

echo "popup Hello, World!" >/proc/empeg_notify

Cool, eh!

-ml

Hmm.. im only seeing v124 on your site...

-Greg

Okay, I've edited the posting.. v124 is correct (I had an internal v125 that confused me).

-ml

Beautiful stuff as always. I love the reboot, now my empflash.sh script can automatically reboot if the kernel files match.

Mark,

What does this khttpd: "index.html" lookups do ?

If you request a directory, say "http://empeg/drive0/" khttpd will look to see if there is a file called index.html in the directory in question. If there is it will serve out the index.html file instead of a directory listing.

At least I guess that's want it does, I haven't downloaded the new version yet...

Yup, that's exactly what it does. Most webservers do (or can be configured to do) the same kind of thing. Useful if you want to hide the contents of a directory from direct viewing, too.. just drop any "index.html" file you please into the dir, and it becomes unviewable. I use this on my webserver to hide "private" content.

Cheers

for us windows users using windows builtin FTP client
ftp> literal SITE EXEC echo "button 20df12" >/proc/empeg_notify

Now where do I find all of the button codes?

The button codes can be found by entering the hijack menu, and using the "Button Codes Display" screen in conjunction with pressing buttons on your remote. Just ignore the codes that start with "8".

Or you could look in the ir_translations section on the hijack website.

Cheers

Speaking of which.. Yes, I am going to be adding "http POST" commands to do what the "FTP SITE" commands do (RO, RW, POPUP, REBOOT, and soon.. BUTTON).

-ml

Cool... another use for Tony's remote control imagemap.

Yes, I am going to be adding "http POST" commands to do what the "FTP SITE" commands do (RO, RW, POPUP, REBOOT, and soon.. BUTTON).

What I would really like to see (rub, rub) is this HTTP interface become a full file management interface. Like this:



What do you think, Mark?

This is a good idea, but I would prefer if it was an option, not the default. Perhaps it could
be like "Fancy Indexing" in Apache where, via the .htaccess file, you can define a header
and footer which would include the necessary forms for your user interface.

What I would really like to see (rub, rub) is this HTTP interface become a full file management interface

That would rule. I don't see a means to changing attributes on existing files, tho. That would make it an almost full file management interface.

Okay, all that we need for this is some html to dress up a directory listing. Anybody want to generate the html?

-ml

Okay v126 has just been released http://empeg-hijack.sourceforge.net/

Improvements from v124/v125 include:

-- http dirlist works again (was broken in v125).

-- SITE EXEC is as broken as before.. I think I'll remove it entirely next release, since the enhancements below pretty much eliminate most needs for it.

-- Popup messages are now used as progress indicators for SITE RO and SITE RW commands in ftp.

-- ftp SITE RO and SITE RW are now implemented internal to the kernel, so they will work fine on a consumer image (previously required the developer image).

-- ftp SITE POPUP command can be used to display a timed message on the front panel, as in:

     ftp myempeg.localnet.



     site popup 99 Flashing new kernel..

     put zImage /proc/empeg_kernel

     site popup 1 Done.

     site reboot

-- ftp SITE REBOOT command now does "SITE RO" automatically before reboot. Note that the Hijack Menu "Reboot Machine" does NOT do RO before booting though..

-- ftp SITE BUTTON xxxxxxxx command exists for remote button simulations. Also works with xxxxxxxx.L to simulate longer presses.

-- Multiple SITE commands can be issued at once, separated by semi-colons.

-- All of the SITE syntax now also works for echoing commands to /proc/empeg_notify as well as for using HTTP GET commands with parameters for /proc/empeg_notify, as in:

http://myempeg.localnet./proc/empeg_notify?button=20df12.L

-- I have replaced /proc/empeg_screen.tiff with a PNG version called /proc/empeg_screen.png --- it is still tiny (32x128 pixels), but if we later put an HTML wrapper around it, we can get most browsers to scale it to a viewable size. I'm hoping somebody writes some HTML to present this screen display along with some buttons that use the parameter syntax (discussed above) to do full remote control.. How about it?

Other changes, but I've lost track..

Enjoy!

Also new as of v126, the SITE RO and SITE RW commands are now fully synchronous, meaning you don't get a response from them until they finish their job 100%.

I'm putting out a v127 shortly, the only difference being that it omits the networking stuff (kftpd, khttpd, and some of the /proc features) when built for a mk1 unit (no ethernet on those).

Cheers.

-ml

I'll start working on HTML for an interface of some sort. I'll keep everyone posted.

Ok, here's my lame attempt at an html interface. Note that this is fairly simple
and I didn't do any image maps or anything (I'll leave that for someone else, or
I'll do it tomorrow after I get some sleep...)

There are three files:

index.html: The frameset file
empeg-display.html: loads the display image and has a 10-second refresh
empeg-control.html: a crude version of the rio remote

Note: my empeg appears to lock up after several minutes when using this.
It looks like the load starts to climb and then it stops responding.

I'll start working on HTML for an interface of some sort. I'll keep everyone posted.

Cool. I was thinking something along the lines of the HTML file management interface that's up for the admins at riocar.org, except without the graphics (don't want to cram those into the kernel).

To support the upload functionality Mark would have to do a bit more work on khttpd, he would need to implement multi part POST requests to process the results of POSTing a form with a "file" type input box on it.

I get the feeling that Mark could implement a cure for cancer and world peace in the Empeg kernel if we asked him to.

Ok I officially suck at java... hehe... I've been trying for about 2 hours to write a script to refresh the empeg_screen image on the page so that there wouldn't have to be a whole frame refreshing, plus it looks smoother, but it doesnt like the .png format. I got it working for .jpg just fine. I threw out the code and am trying again but its 2:44am and i've got class in 4.5 hours. Anyone have something like this? i suppose its the same kind of script that is used for refreshing webcame images on a webpage. If you do post it or email it to me at greg@mandiola.com. I got something kinda cool worked out ; ) but i need this as a start to the (short) developement.

-Greg

> Note: my empeg appears to lock up after several minutes
>when using this. It looks like the load starts to climb
>and then it stops responding.

Mmm.. yes, the khttpd threads seem to be getting stuck in Zombie status, rather than dying away like they were supposed to do. So the machine just runs out of memory after a few (re)connections. Maybe this is why ftp sometimes fails (once every hundred or two files). I'll look into that and fix it (somehow).

-ml

Yeah, sorry for the .png, but it's the only lossless image format that all browsers understand. Pity it's so bloody complex, even for an uncompressed image like the screen dump.

If you'd prefer a raw packed pixel dump, I can provide that as an alternative, almost for free. But it's easy enough to extract from the .png as well. Just remember, in the IDAT section, every screen row is 33 (not 32) bytes -- throw away the first byte of each row (a "null" filter code), and keep the other 32 bytes. Within each byte are four 2-bit pixels, laid out in viewing order from msb to lsb (silly png!!). All of this is at offset 48(decimal) from the first byte of the png file; the rest of the file can be ignored.

-ml

>I get the feeling that Mark could implement a cure for cancer
>and world peace in the Empeg kernel if we asked him to.

Curing world peace is easy.. already been done a thousand times.
But curing world unrest is much more difficult.. not enough memory.

Ok, you know about this then. I was about to post my capture on it, the empeg didn't like my javascript autorefresher.

And would would people prefer, a Javascript based autorefresher, or a java one?

(Ugg, looks like we have a nother round of Nimda running around here again. Looks like that could freese up my empeg, time to move it to the test network again)

Smart ass.

Drakino. I'd say javascript. That way its easily customized and inserted. (plus probobly smaller in size, which I guess doesn't matter since it will be like 30k if that). I still havn't gotten it to work yet. If anyone gets it to work please post it. I'll do the same.

-Greg

< script language="JavaScript" >

function cycle() {

  document.empegScreen.src="http://empeg/proc/empeg_screen.png"

  setTimeout("cycle()",1 * 250)

}

< /script >

< img src="http://empeg/proc/empeg_screen.png" name="empegScreen" border="0" width="128" height="32" >

< script language="JavaScript" >

cycle()

< /script >

That will refresh the image every 250 ms. Keep in mind with the current zombie problem, this will crash the empeg in under a minute.

I dont seem to be able to get that to work here. It requests from the empeg, but the image is not refreshed.

The meta tag refrest works, and is a fast update with 0.5 and below although a little flickery but as mentioned crashes the machine very quickly.

On a side note a friend who said it was too expensive for him in the xmas rush is now immensely jealous

What browser are you using? I think I may not be using one of my old universal methods for referring to an object, so it may not work outside of IE.

I'll dig up some of my Javascript coding to see the best way to do it.

Forget *FILE* management. How about a Jukebox manager?

Basically an HTML interface that *EVERYONE* in the office can use to "request" songs. Songs that are requested are queued up. The empeg can then be hooked up directly into the pager system of the office, and voila!!!!

Calvin

Forget *FILE* management. How about a Jukebox manager? Songs that are requested are queued up. The empeg can then be hooked up directly into the pager system of the office, and voila!!!!

That would be a cool thing to implement as an external program using the Emplode protocols. You could distribute it as a client program to each of the workstations. Each workstation could insert one song at a time (using the emplode protocol's "insert" feature), and then would lock the user out of inserting anything for the next ten minutes or so (so no one would monopolize it).

A little work with password protection would need to be done to prevent someone from just running Emplode and taking over the player, but it's do-able.

Sounds like a fun idea for small offices.

Since Mark implemented HTTP methods for controlling the player.. it seems like it's one step away from complete HTTP access to the player. You don't need the empode protocols (though it can be done with I guess).

It seems to me, that you have designate one machine as the "gatekeeper" to the empeg, install the jukebox queue there, and that machine has the necessary software to connect to the empeg and insert songs, etc. The "gatekeeper" machine is also running a web front end that loads the queue. Pretty simple, no need to install any client programs anywhere.

Calvin

Inserting songs into the players current playlist pretty much has to be done with the emplode protocol. However, there could in theory be a daemon running on the player that connected locally using the emplode protocol, but then accepted HTTP request and passed them through to the player.

This sort of thing doesn't belong in the kernel however...

Since Mark implemented HTTP methods for controlling the player.. it seems like it's one step away from complete HTTP access to the player. You don't need the empode protocols (though it can be done with I guess).

I guess you could do it that way, yeah, my point was that it sounded like a good project for a third-party app that didn't depend upon a hacked kernel. Seems like it could be done pretty easily with a subset of the Jemplode code. It's always nice when something can run against a stock player with the default consumer build installed.

Almost everything in Hijack belongs in the player, not the kernel.

But the player is closed source, and uses proprietary (though published) non-extensible protocols to communicate. So that leaves us with a very hackable kernel.

Speaking of hacks.. is there a way to use the remote or the serial port to feed a "FID" to the player??

-ml

Fair point, although I think adding code for the emplode protocol into the kernel would be more bloat that we need...

There was a command to play a FID from the serial port, but I believe it stopped working many builds ago.

Take a look at this post for an answer.

Not so much an answer...

I'm still wondering why it isn't working.

If you can FID or script-FID the player, then I can see the beginnings of speci,alist off-empeg control programs.

I think you take the empeg not as a computer, but at face value -- hardware that plays music... then indeed, you can argue that some of this stuff "belongs" in the kernel. (yeah, the argument is weak because there are alternatives for functionality placement ). In any case, given that "playing a song" is associated with the hardware, then you could wrap that with some HTTP compatible control mechanism and create firewall friendly, network friendly, web based software that leverages the box pretty easily.

Calvin

The crashing (after a while) is now fixed in v128.

It took, like, forever to find the magic flag that wait4() wanted for it to "wait" on kernel threads..

-ml

Im using IE 5 so something's a miss somewhere
Still a problem with Hijack V128

Its working really well now in the web browser with meta refresh set to 0.1
The only problem being that the refresh flashes the .png file, it reminds me of some of the old AMiga demos
Is there any way to have a real time display update without the flashing? The best I could think of is some sort of quicktime stream, but then I hate QT so...

That Javascript method above dosen't have a flicker (Are you removing the spaces I had to add around all the tags?), and a Java applet would also be able to do it with no flicker.

Let me dig up a premade java applet for web cams here real quick...Here we go.

Ok I did this at my G/F house (see attached) in notepad and paint for a while till i got home since she has nothing good for editing on her computer. This is really simple to make but I know there are some out there that don't have much design experience so I decided to write this. It need hijack install but it can be run from whereever you download it or in your / dir on your empeg as long as your empeg ip is 192.168.0.2 otherwise you'll need to change that. I had a problem with linking the empeg fascia around the display screen with the javascript that was posted. It would leave a white line on the bottom of the display ; / If anyone can get this to work please post. I set the display to update every 3 seconds you can change this very easily. If you guys want me to work on this more I'll be happy to.. this is just a rough design to see how it all looked. I was trying to make something in flash so a blue/green/red transparency could be put over the empeg_screen.png and make it look like your player. The problem is getting the empeg_screen.png into the flash and refreshing it. Let me know what you thing.

-Greg

ohhh!!!! you sod!
Guess what I just finnished doing...

Right thats it, Im off to bed...

IIRC flash lets you do transparency, so could you not just use the .png file as a backgrouns image and have the flash movie over the top, with an option to select the colour of your face plate?

Hehe.. post yours.. im interested in seeing you idea. ; )
-Greg

well, I just finnshed the code for the image map (I cheated, used FIreworks) and it was a dodgy attempt at using my girlfriends new digicam Its embarassing in comparison, but Ive attached the code anyways for a laugh.

Here is a ScreenShot of the source I posted above. Just to know what your downloading.

Oops, found the problem. I grabbed some old rorational image code, and stripped it down. I though I had saved and verified it, but I just went back to my HTML editor and realised I missed the save button

Attached is the updated screen.htm with Javascript Based rotation. I'll work on using that Java webcam one above here in a bit.

Me too !!!

I was just putting the finishing touches to my player graphics when it was posted...

You guys are insane!!!

Okay, a couple of notes for you script/java/flash writers:

The latest (v128) hijack now supports "GET" with parameters and any (or no) pathname.. this may make button pressing easier for you.

Eg. instead of: "GET /proc/empeg_notify?button=20df12"
you can now do: "GET /?button=20df12"
or even: "GET /proc/empeg_screen?button=20df12"

And I'm looking a a table-based CRC32 to see if it's any faster than the on-the-fly CRC32 currently used for the .png encoding -- see if the load on the empeg can be further reduced with it.

And if anyone wants a non-PNG version of the display (for flash importing or whatever), let me know.. not sure if it will speed anything up, though, since even my PNG version does NOT actually compress the image.

Cheers

-ml

Hehe. if anyone else was working on one post them I'd like to see your guys idea. If enough people are going to use this i'd like to get it up on a website for people to download from. I'd stick it on my server but anymore traffic and im gunna have to get a loan hehe. Let me know if you guys have any idea's to make it better.

-Greg

That Java applet dosen't work with PNG images, so no go without modifications.

Has anyone looked at the Java file from Displayserver? It had support in it for color. In theory, a few modifications (possibly with a raw feed available in /proc), it should work pretty well.

The odd thing is that Sun says 1.30 and higher supports PNG images. Maybe it has to be compiled and run under that version. (I'm running 1.31 here). I don't have all the tools here to recompile it and try, and I'm heading home for my weekend once this call is over.

You can improve your .html scripts if you use "relative" paths instead of hardcoded ones. Eg. instead of "http://192.168.0.2/proc/empeg_notify?button=20df07.S just use "/proc/empeg_notify?button=20df07.S".

Note that the ".S" is totally ignored, so it should get removed.

And with v128 hijack, this all becomes: "/?button=20df07"

Cheers

Don't think flash is possible, i've been looking around. I've attached the latest files to this one. It has Drakino's refresh javascript and I added controlls on the empeg fascia. For volume the top have increases volume and vice versa.

-Greg

Also, I'd like to see a larger image size. If you add WIDTH=256 HEIGHT=64 to the IMG tag for /proc/empeg_screen.png, then it becomes readable. Could somebody have a go at that, with larger facia to match?

This is just soooo CL!!

Noproblem. I'll work on it when I get home. No image editing tools here for the fascia. I just set it small since the empeg_screen.png is really nice at the size it is now. I tried expanding the .tiff when it was set to that and it didn't look as nice. Maybe png will look better. I also just set in the 192.*.*.* so it could be ran right away without having to upload it so you can modify it a bit. I'll post the next one with relative paths. Anyone know of a way to make a link not actually open a page? I had to add that other frame in the upper right corner so that everything would work, there has to be a better way.

-Greg

Any known issues with load problems and the kftpd in v128? I just had an ftp session lock, and the setail port, plus kftp/khttpd are unresponsive. Vitals show load of 202.30, 166.56, 87.something...

The button links send "GET " commands, which REQUIRE loading a page of some kind.. but you could "GET /dev/null" for really short ouput. Maybe I'll redirect "?button=xxxx" to /dev/null in v129, just for a trial.

Also, table-based CRC32 turns out to take 1/10 the CPU usage (I measured it) of the non-table version used in v128. So, I guess I'll waste another KB on a CRC table..

Cheers

Hey Mark why was site exec removed from kftpd? Permanent change or just remodeling?

No, solid as a rock here, until beta7 crashes on its own (rare, now that I have reserved=9 in config.ini).

It was giving me too much grief, so I nuked it -- non synchronous, no output, etc.. and not really required for a "stripped down" kernel kftpd.

I think just running a telnet server would be a better idea, and they're easy to install with kftpd now. I'll eventually see about program launching from config.ini, where being synchronous isn't a big deal, but I just got terribly frustrated with it all today.

Cheers

Okay, v129 will be out shortly:

-- http "GET /?button=xxxxx" now returns NO DATA WHATSOEVER.
-- http "GET /?" also now returns NO DATA
-- the .PNG encoder now uses a table-lookup version of the crc32 calculation, which reduces it's CPU load by a factor of 10 (for just that portion of the PNG code).

Nothing else (that I remember).

Cheers

Gotcha... Good reasons. So where's ktelnetd?

No I'm not at all serious about that. I was thinking of getting telnetd on my Empeg at some point but I didn't want to waste the memory. Actually I still don't.. Forget I mentioned telnetd.

Tried out your code here, very cool! Only thing is I couldn't get javascript refresh to work. So I modified your code a bit, this method of cycling is dead simple, just attach ?nocache=x to the url where x is an incrementing number. See the code attached.

Hmm.. the code you just posted was just like the one i tried writing last night. For some reason it doesnt work for me. I'll have to look into this.

-Greg

Ok attached is the most resent updates. I've done a few more things with this one. There are not more static links (unless I forgot to take one out here or there). There is also a built in option to view the empeg large or small. I couldn't find an easily modifiable fascia that would with on the 2x screen so i just blew up the small fascia. If anyone wants a better looking one I can do it, no problem. I actuly don't think it looks too bad. I also fixed a few buttons on the empeg that were set wrong.
Let me know if theres anything else I should put in here. I also tried making this out of flash and i can't get the screen to refresh. If anyone has a better way of updating the screen please post. The way right now is ok but it could be a lot better.

-Greg

A few absolute URL's (with 192.168.0.2) are still hanging around in
screenlarge.html
screenregular.html
index.html

Buttons aren't working for me on this one.. Not sure why.

Anyway Flash is nice I think a Java applet might work well. Frank certainly had that part of it nailed down with display server. Java is also much more portable than Flash.

The buttons use new features in Hijack v129. If you upgrade they should work. I'll fix the statcs ; ) . Java would be nice but I only have experience in javascript not actaul coding.. I guess its never too late to learn.

-Greg

Ok here is the latest. I went over everything to make sure it works. I also removed all the statics ip's except for the main ftp:// link. Anyone know how i can make this load to show the directory of the empeg without having it static? I tried "/" but it didn't work. MAKE SURE YOU HAVE Hijack v129 or this wont work without modifying. You should be updating Hijack every release anyways, hehehe.

-Greg

Hey Mark,

It looks like IE6 doesn't like the FTP server in v129 anymore. In v128, it worked fine, but now with v129, IE crashes as soon as I try to contact my player via FTP.

HTTP still works fine though.

I'm runng the XP version of IE6, BTW.

Hmm. It works fine for me. I just tried it on my WindowsXP box with IE6. Check windowsupadate I think there was a something that needed to be patched with the ftp and some other stuff in IE6. Plus if you havnt already you can patch the nasty exploits that were found.

-Greg

Actually, this is exactly how I got into mp3s.

Back at warwick university, where myself, Mike, Roger, John and John also went (though not all at the same time), there was a terminal room in the CS dept called the Fyshbowl, because it had glass walls.

This is where all the geeks hung out, despite the room being starved of decent hardware (lots of ADM-3As, a couple of IPCs, several ELC(?)s and one Sparc 5 a bit later on).

Anyway, people got to finding sun 8khz mono .au files around on the net, and built a jukebox/chat server. You could log into it, chat, search for music and play it (queue it up), which was used for general entertainment for everyone in the room.

When the sparc 5 came on the scene with its bigger speaker and better sound (22khz?) people found l3dec and integrated it - it didn't have enough CPU for full rate decode though! I used to record (at 22khz) my CDs on my pc through an analogue connection, mp3 encode them and bring them in on floppies to build the library.

Later versions even had fair queuing, so if someone had queued 10 files then another used queued 1, it'd go in as nr 2 in the list.

Richard Neal was the original perpetrator

Hugo

Same problem here. With W2k and IE60. V128 works also ok.

bye

I just checked Windows Update again, and theres nothing new in there. I check it at least once a day, so I'm usually pretty on top of updates. The only stuff that I haven't downloaded are completely nonsequiter, like the "Euro Conversion tool". Don't think the stuff that's in there has anything to do with the problem I'm seeing. Keep in mind, that it works fine with v128. I backgraded to that, and sure enough, it works fine again.

This is awsome! GREAT JOB!

this could be a browser problem I was using IE 5.0 what browser were you using? Javascript is notorious for not being standard. I get the feeling also that IE doesn't handle PNG image rollovers as smoothly as it does gif and jpg files, the support for png files in IE has never been perfect.

Well, that is easy enough to fix: just insert a Mandrake-8.1 installation disk into the CD-ROM tray, hit the reset button, and choose "fully automatic" installation.

Or you could try connecting up your serial port, setting [hijack] kftpd_verbose=1 in config.ini, and then running ftp again, and sending me some useful diagnostics.

Cheers

>Ok here is the latest. I went over everything to make sure it works.
>I also removed all the statics ip's except for the main ftp:// link.
>Anyone know how i can make this load to show the directory
>of the empeg without having it static?
>I tried "/" but it didn't work.

Well, now that you've got it looking really pretty-like, I've probably gone and broken it again.

Hijack v130 is out, and the changes that affect your awesome scripting are:

-- http "GET /some/path?options" no longer returns NULL, but rather fetches the path as in pre-v129 versions. So if you want button presses to not waste bandwidth, then point them at /dev/null, as in "GET /dev/null?button=20df12"

-- http "GET /any/directory/?anything" now skips the search for "index.html". This means the "ftp://static_ip/" can now be replaced with a simple "?"" (I think), or perhaps "/?"

Other new stuff in v130:

-- new "SITE RW /" command: rw remount of / only
-- new "SITE RW /drive0" command: rw remount of /drive0 and /
-- new "SITE RW /drive1" command: rw remount of /drive1 and /
-- ftp "CWD" command now validates the new directory path
-- the .png generator is faster and smaller than before
-- the .png generator is now re-entrant, allowing multiple simultaneous connections to /proc/empeg_screen.png

Cheers

I did again some tests and found the problem. The problem is when I start to edit the index.html. If I do open local on my PC the original file from empegweb13 then it works. But after editing with Frontpage or Ultraedit my Internet Explorer 6.0 hangs.

I did only change my IP Address.

Any idea why?

bye

Sorry,

Some addional information. If I change the IP back to 192.168.0.2 then it works again...So I think there is a bug somewhere in the empegweb! But for mandiola and mlord is this peanuts .

Thanks

At this point, I haven't the foggiest what you are having a problem with. Can you post a URL that does not work for you? Or is the FTP server not working (try something like ftp://my.empeg./proc/)

Any chance of using meta tags to refresh ONLY the empeg_screen.png image, rather than the current javascript? I ask because Communicator doesn't do refreshes for the latter method (under Linux). Mozilla works, though, but 0.9.7 is wwwaaaayyyy too buggy for general use yet.

Cheers

Okay, I replaced the FTP reference with a simple src="/?" for Hijack v130, and it works well. But if you descend a directory, and then click on "..", one end's up with a nested page -- because of the "index.html" name of the main file. So, I've renamed "index.html" to "RUNME.html" to get around the problem. Works FANTASTIC now!

Now all that is needed is a little more JavaScript for the button presses, to distinguish between LONG and SHORT presses somehow.

In aid of this, I'll add a "buttonraw=" command that only sends a single press or release code into Hijack. The current "button=" command automatically sends a press followed by a release, which makes it harder to do synchronous press/release events from a web browser..

Look for "buttonraw=" in hijack v131 shortly.

Cheers

Mark,

I did delete all the empegweb Files on my Empeg. And then the HTTP and FTP Connection to my Empeg is working (Hijack V130). But If I go to install the latest version 1.2 or 1.3 from empegweb it does not work.

This means: I did the change the IP-Address in the index.html from 192.168.0.2 to 10.0.1.10. And then It doen't work. I did try to browse empegweb on my local machine. Not on the Empeg. But the same problem is also on the Empeg. I did only try to get out where excactly the problem is. If I go and change the IP-Address back to 192.168.0.2 then I can browse it locally again.

So I thinks there is a little problem in the Empegweb application.

That's reasonably easy, by using the mousedown and mouseup events (and a timer variable) instead of the onclick event.

I never removed the button catch. So when you click a button it still goes to that frame. It saves a lot of problems. So that doesn't need to be changed for v130. I'm looking into other was to show the empeg screen since updateing the picture the way im doing it now is kind of obnoxious since its choppy and makes the mouse point go crazy. Hopefully I'll get something out tonight since this seems like something people are enjoying. I think i'll also setup a webpage, unless (Mark) you want to set me up someway I can put it on the page with Hijack since they do go hand in hang ; ) I got to go to work and network an office so i'll work on it when i get home.

-Greg

heh heh... sounds cool.

I'm a little busy at work today... I'll try it when I get home tonight.

So... Where exactly is it going to spit out the debug info...? I'm guessing it makes some log file somewhere?

I think I found finally the bug. First I did try the empegweb with Linux. There is the app. really working well.

But I deleted in the index.html the line with the ftp info and then it works.

bye

If you want to visit http://sourceforge.net/ and create a userid for yourself, then I can add you to the "empeg-hijack" project to give you direct access to the directories there..

Or you can find another home for your wonderful hack, and I'll put a prominent link for it onto the hijack site.

Cheers

Or you could try connecting up your serial port, setting [hijack] kftpd_verbose=1 in config.ini, and then running ftp again, and sending me some useful diagnostics.

Well, I'd love to do that, but I can't seem to figure out how. I'm at a loss here... I made the config.ini change, but where does it output the debug info? Is there a log file somewhere or something? I can't seem to find it... Do I need to be using the dev image?

Also, I tried the command line version of FTP, and that works fine. It's only the IE6 FTP that's having the trouble. I just tried Hijack v133 too, and same thing. IE hangs immediately...

The debug output will appear on the serial line, which you can connect to with kermit, cat, or even hyperterminal, and it will show exactly what the issue is with your FTP client not liking Hijack.

Cheers

*Me shoots self*

ok... I should have been able to figure that one out. I blame it on the fact that I've been sicker than snot for the past week...

Anyway, here ya go...

kftpd: connection from 192.168.0.42
kftpd: 220 Connected.
kftpd: 'USER anonymous'
kftpd: 230 Okay.
kftpd: 'opts utf8 on'
kftpd: 500 Bad command.
kftpd: 'syst'
kftpd: 215 UNIX Type: L8.
kftpd: 'site help'
kftpd: 216-The following SITE commands are recognized
BUTTON CHMOD HELP POPUP REBOOT RO RW
216 Okay.
Bad mode in prefetch abort handler detected: mode SVC_32
Vectors:
00000000: ef9f0000 ea0000cd e59ff3d0 ea0000bb ea00009a ea0000ea ea000078 e3a0c0
04
00000020: e58bc018 e5dac000 e5dad000 e18cc40d
f8
Stubs:
00000200: e59fd1dc e24ee004 e58de000 e14fe000 e58de004 e3a0d093 e161f00d e20ee0
0f
00000220: e79fe10e e1b0f00e c0009e20 c0009bc8 c0009bc8 c0009ce0 c0009bc8 c0009b
c8
00000240: c0009bc8 c0009bc8 c0009bc8 c0009bc8 c0009bc8 c0009bc8 c0009bc8 c0009b
c8
00000260: c0009bc8 c0009bc8 00000000 00000000 00000000 00000000 00000000 000000
00
00000280: e59fd164 e24ee008 e58de000 e14fe000 e58de004 e3a0d093 e161f00d e20ee0
0f
000002a0: e79fe10e e1b0f00e c0009de0 c0009bb4 c0009bb4 c0009c80 c0009bb4 c0009b
b4
000002c0: c0009bb4 c0009bb4 c0009bb4 c0009bb4 c0009bb4 c0009bb4 c0009bb4 c0009b
b4
000002e0: c0009bb4 c0009bb4 00000000 00000000 00000000 00000000 00000000 000000
00
00000300: e59fd0e4 e24ee004 e58de000 e14fe000 e58de004 e3a0d093 e161f00d e21ee0
0f
00000320: 059fe004 159fe004 e1b0f00e c0009ee0 c0009ba0 00000000 00000000 000000
00
00000340: e59fd0a0 e58de000 e14fe000 e58de004 e3a0d093 e161f00d e20ee00f e79fe1
0e
00000360: e1b0f00e c0009e80 c0009bdc c0009bdc c0009d60 c0009bdc c0009bdc c0009b
dc
00000380: c0009bdc c0009bdc c0009bdc c0009bdc c0009bdc c0009bdc c0009bdc c0009b
dc
000003a0: c0009bdc 00000000 00000000 00000000 00000000 00000000 00000000 000000
00
000003c0: e25ef004 eafffffe 00000000 00000000 00000000 00000000 00000000 000000
00
000003e0: c000a000 c0102960 c010296c c0102978 00000000 00000000 00000000 000000
00
00000400: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffff
ff
00000420: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffff
ff
00000440: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffff
ff
00000460: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffff
ff
00000480: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffff
ff
000004a0: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff

Internal error: Oops: 0
CPU: 0
pc : [<4f4f4244>] lr : [<00000072>]
sp : c0441f88 ip : c0103cc4 fp : 00000000
r10: 000000d8 r9 : 00000000 r8 : 52202020
r7 : 5055504f r6 : 50202020 r5 : 20504c45 r4 : 48202020
r3 : 00000000 r2 : 00000072 r1 : c08421d0 r0 : 00000000
Flags: nZCv IRQs on FIQs on Mode SVC_32 Segment kernel
Control: C000517D Table: C000517D DAC: 0000001D
Process kftpd (pid: 24, stackpage=c0441000)
Stack:
c0441fc0: 00000072 4f4f4244 60000013 ffffffff 52202054 2020204f 52202020 320a0d
57
c0441fe0: 4f203631 2e79616b c0000a0d c00fc5c4 c00cf334 c00cf3c0 c00cf334 c000b4
44
Backtrace: no frame pointer
Code: pc not in code space

IE6's FTP client is terrible. Just use any other FTP client fro W32 platforms. My favorite's SmartFTP, and that's free. There are dozens out there, a lot of them are free, and all of them are better than IE6's built-in one. IE6 is a great browser, I believe, but a really really poor ftp client.

Any chance of getting hijack menu options for these mount options now that the commands themselves are in the kernel?

For that backtrace to have any meaning, I also need to know exactly which Hijack version was installed at the time of the crash..

Never mind.. found it. Buffer too small for new response_table[] code in ftpd.. only crashes if you use the HELP or SITE HELP commands.. Doh!

Fixed in the forthcoming v135.

Cheers

heh... I was just going to say, nevermind, it's fixed in 135...

IE6's FTP client is terrible.

Heh, you can say that again. I've never tried SmartFTP, but I think any FTP client has to be better than their built in one. I used CuteFTP back in the day, and I loved that app. Haven't gotten around to installing it on this system yet...

And now it works for me also with V135 and IE 6.0!

thanks a lot.

Kind of off topic. forgive me please, but I was browsing earlier and was reading about someones proposal to MLord to make a "file writable area". A thought is that possibly I could use the XML dump option in emplode and dump this file and move it to the root and use a XSL to make it queue software that writes to the "file writable area" that of course is assuming we could possibly play song by fid? just a thought though?

silmonkey

I wrote a small program in vb that connects to the empeg and then flashes the hijack kernel to the one you choose through ftp. I still have a little bit of work left on it to make it more user friendly. I need to add 2 things to it. Does hijack have any ftp calls that will (1) pause the player and (2) reboot the player? I have it so that it dectects to see if the player is flashed first, but then i need it to reboot it... and more importantly, pause the player before it tried to flash it to make everything work faster.

-Greg

>Does hijack have any ftp calls that will
>(1) pause the player and
>(2) reboot the player?

Your script should do something like this:

site popup 999 Downloading new kernel
binary
put v137.hijack...zImage /proc/empeg_kernel
site popup 2 Done
site reboot


You could also try using "site button 20df16" to pause the player, but since the "pause button" is actually a toggle "pause/play", it's kinda difficult to guarantee success that way.

-ml

Hmm... site doesnt work for me.. can't do site popup.

-Greg

On which version of HiJack? Works for me on 136.

Just in general.. im trying to send it through a dos ftp for testing.

-Greg

Same here. It's just that features get introduced, improved, broken, fixed again, and all site commands (and others, for that matter) I tried seem to work in 136.

Ahh i got it... forget that windows ftp needs literal in front of it ; )

-Greg

Hmm.. vb doesn't like literal nor just plain old SITE. Im using inet control and it works for PUT but nothing else. Any suggestions.

-Greg

Hm, I was using cmd-line FTP client that comes with Cygwin (port of bash shell, gcc and assorted *ix utils to Win), and it works OK. The client that comes with Win98 does not seem to support SITE command at all (HELP does not list it).
A GUI ftp front end (LeechFTP) I sometimes use lets you issua arbitrary command, so SITE works there, as well.

Try to search around for free full implementation of command-line client (or download LeechFTP - I don't remember where I found it - TwoCows perhaps?). Sorry, I have nothing more helpfull...

Here is the link to LeechFTP free , and best FTP freeware avalaible in many languages :
LeechFTP

I think you guys are missunderstanding what im doing. Im writing a program that lets you quickly update the kernel through ethernet. All I have left is to display whats happening and make the empeg reboot, otherwise it works perfectly.
Im not having problems uploading or anything like that.
-Greg

OK. Still havn't gotten EtherFlash to send what its doing to the empeg screen. I am going to post everthing at: http://www.empeg.tk in a few minutes. I will put up my empegweb and this EtherFlash that I've been working on + the source. So if anyone can get it to show up on the screen let me know. Its a really simple program I wrote in a few minutes.

-Greg

I know a little vb. Instead of using the inet control, you could use the socket control and just send the raw commands. That would allow you to use SITE.

Tom