Hijack v99, New Site

Okay, Hijack v99 was released earlier today.
Nothing major -- just a bugfix for the new "vitals" display.

But.. As of maybe half an hour ago, I have relocated my empeg site over to SourceForge, to reduce the ever-increasing strain on my ADSL link.

The new location for Hijack is http://empeg-hijack.sourceforge.net/

The old http://rtr.ca/empeg/ will still appear to work, but it in fact just redirects all traffic to the new location above. Please let me know ASAP if there are any problems accessing the site and/or files.

And, oh yeah, it's a good time to try Break-Out on this version of Hijack.

Cheers

-ml

I see you don't respect the Great One as much as some of us would like.

I see you don't respect the Great One as much as some of us would like.

Have you looked at the release notes for 99?

I guess that's what I get for being a jackass.

You gotta love it.

Ok, someone send me a private message with details of the new addition (so as not to spoil it for anyone else). I'm not going to be able to use my empeg for a week and I'm way too busy tonight to install hijack...

Bruno

v99 Will still be up whenever you're ready to try it.

Cheers

Hey, I'm *THAT* impatient.

Bruno

I have a seriously stupid-ass question the answer to which is probably sitting right in front of me. Anyway, here goes:

Assuming I write a userland app to plug into Hijack, how do I get it on the empeg?

Oh, wait. I get it. You have to install a developer image because that does more than just update the kernel. Duh. That's what allows me to log into the box.

Assuming I write a userland app to plug into Hijack, how do I get it on the empeg?

In theory, we let Mark finish the kernel FTP addon to hijack (says the man using SMU's Stupid FTP to clone his player )

I know one of the other nice features Mark shows on his wishlist is userland program launching from config.ini options. That to me seems more useful then having programs running at all times to get a menu entry.

The last big piece of this developer puzzle is getting an easy to install method down. This also includes doing the necessary processing on the empeg side like init hacking if necessary. The overall goal of getting an API of some sort to allow users with no shell knowledge to add programs is definitly much closer then it was this time last year. (Unfortunatly my skills in this area haven't advanced much, so I'm still not too much help beyond ideas).

I am getting my empeg popping out of standby when it has hijack on it after about 6 hours or so.

The feature of the timer is very useful to me as an alarm clock if it didn't wake up early what would really rock would be an alarm clock type alarm as in set to wake up at a certain time

>I am getting my empeg popping out of standby
>when it has hijack on it after about 6 hours or so.

I don't see this behaviour on mine (which sit on stby overnight).
Could be a beta bug, I suppose.. sounds iffy.

Anyone else?

-ml

Well, actually, number 99 was retired in v100 last night.

But v101 is now out. The big difference is a (yet again) revamped "vitals" display, this time with some useful info for those folks with 3-4 empegs kicking around.

"Vitals" now shows: model:drive0(+drive1), temperature, Playlist, Fid, VMstats, and LoadAvg.

Let me know if it doesn't work for you, particularly if you've got a Mk1 or any two-drive units.

Cheers

-ml

v101, Vitals doesn't pick up the FID on my MkI 2-drive unit. Do I need to set notify=1 or something else in the config.ini for this to work? It does pick up the playlist correctly.

/Michael

Yeah, for the FID to display, turn on notify:

[output]

notify=1

Also, if you don't actually want the overhead of all that spewing of notifications out the serial port, you can (in addition) do:

[hijack]

supress_notify=1

Do both of your drives show up in Vitals? Accurately?

Thanks

Will go right ahead an fix the config.ini.

Yep, the two drives (2x10GB) shows up correctly.

Edit: After applying the notify=1 and supress_notify=1 it works as advertised

/Michael

excuse my stupidity, but where are these, or is the Revision History notes on the site that Im looking at, them?

Cheers

Dave

The Hijack downloads (kernels & instructions) are at http://empeg-hijack.sourceforge.net/ and the "drive information" is on the "Vitals" screen, accessed from the Hijack menu (push and hold MENU button or front KNOB).

-ml

It does not work for me .

I edited the config.ini file , sync , reboot the player but it dont display the fid.
Here is my display :
Playlist:0000, Fid:

It displays my 10 GB drive, temp, cach, buf ..

Time to double check your config.ini.

Make sure there is not a duplicate "[output]" section somewhere.

To recap, you need these two lines in config.ini.
I suggest putting them at the very bottom,
to avoid messing up anything else:

[output]
notify=1


???

I did verify my config.ini :
No duplicate line and i put them at bottom of file.

Still not fid display

Hi.

That is very weird.

Could you please ensure (1) that you do NOT have "supress_notify=1" in config.ini, and then (2) connect to the serial port, hit "next track" on the remote at one second intervals, and then tell me what you DO see on the serial port. Thanks!

-ml

The big difference is a (yet again) revamped "vitals" display

On my new player (Mk2a) with 2 drives, I loose the last line. Here is what my display shows:

Mk2a:29G+29G, +49C/+12

0F

Playlist:0000, Fid:3170

Cach:1092,Buf:91,Free:97

Thanks!

I was wondering if it would fit, and was too lazy to count pixels.

I'll shorten the top line a little for the next release.

Cheers

Okay, I just released v104 of Hijack.

This version has some bug fixes, source code reorg, and the initial skeleton for the kernel-based ftp daemon (kftpd).

-- fixed quicktimer conflict with 'Search'
-- fixed 2-drive display on Vitals screen (I think)
-- fixed quicktimer conflict with menu button
-- split out hijack.c completely from empeg_display.c
-- added kftpd.c version 0.1

The kftpd is NOT too useful yet, unless you know what you are looking for. It currently can only retrieve files ("GET"). It can NOT list directories yet, and it cannot upload files yet. Those features will follow in the not too distant future.

It currently runs on port 91, to avoid conflict with any other fully functional ftp daemons people may be using. For a demo, try this:

ftp  1.2.3.4  91

get /bin/init junk

quit

Of course, use the actual ipaddress of the player, not 1.2.3.4.

I do NOT want to hear any bug reports on kftpd for now.

Cheers

-ml

fixed 2-drive display on Vitals screen (I think)
Looks good here. Sometimes the cache buffers line will get too big, but it's rare.

fixed quicktimer conflict with menu button
Looks good

fixed quicktimer conflict with 'Search'
Works ok now on the PIN and Year search screens, but Quick timer still pops up for me on any of the other search screens.

>fixed quicktimer conflict with 'Search'
Works ok now on the PIN and Year search screens, but Quick timer still pops up for me on any of the other search screens.

Oh, found another problem on the way home, 4 poped up the quick timer when the tuner was active, instead of going to the 4th preset.

Thanks for the quick testing!

Okay, v105 is out, and "Search" is really fixed this time, all modes. And I deleted a couple of chars from the page-stats so they have a better chance of fitting on the screen when the player's not running.

No changes to kftpd in v105.. I'll be working on directory listings next.

-ml

Okay, Hijack v107 is out.

http://empeg-hijack.sourceforge.net/

-- kftpd now does directory listings, so you can browse your empeg from a webbrowser by using ftp://1.2.3.4:91/ (replace 1.2.3.4 with actual ipaddress or hostname).

And, yes I know the dir listings are not yet 100% correct for "special files" like devices/fifos, and the dates are all wrong. But it works!

-- bonus feature: new config.ini option "standby_minutes=30" (default) to automatically shut down the player after an interval after the screen blanker fires.

Cheers

-ml

Mark, thank you so much for kftpd. That's going to be extremely useful for me.
I was wondering, are you going to implement some sort of id/pwd system to prevent from unauthorized access on large networks? Maybe you could add username and pwd in the config ini, with two levels of access. rw and read-only. What do you think?
Again, this is a simply great featiure, expecially as an alternative way to clone tow empegs in case the clone feature fails...

Well, currently anyone on your network can run Emplode and completely fsck your Empeg player.. no passwords.

For kftpd, I will probably just add a front-panel-only menu item to enable/disable it. but not until it gets to the point of being dangerous (upload and rexec).

Cheers

Well, currently anyone on your network can run Emplode and completely fsck your Empeg player.. no passwords.

Not strictly true -- emplode _does_ support password protection, but it's not used by the car player.

That's interesting. Will the player use pwd protection in future sw releases? That's really important in my view. I guess many of us have their player connected to their offices' lan, which is quite unsafe w/out pwd...

Thank you

Cool cool cool.

Okay, now for the next rub on the lamp.

I'm on DHCP now, both at home and at work. Let's say, for the sake of argument, that I don't like looking up the IP address of the player every time I want to do something on the player.

Right now, the player doesn't identify itself on the network by name. I don't know how it's handled in a Linux system like this, but I can type PING <computername.company.com> where "computername" is the PC's Windows Network Name, and it works. Is there any way to get the player to identify itself by name in this same way, so that I don't have to look up an IP for it? Can it be done in the kernel or would that need to be integrated with the player software?

Why not just set the empeg to a static ip? Its not using any features of DHCP such as getting dns settings so you don't really need it set to it. Why not just something like 192.168.0.2?

-Greg

The only way to do what you are asking is to update your network's DNS and/or DHCP tables such that they "know" the EtherNet-ID of the Empeg and can thus map a static hostname to it (Regardless of IP address).

That's the same way it works for all of you "named" workstations and network nodes.

cheers

The only way to do what you are asking is to update your network's DNS and/or DHCP tables such that they "know" the EtherNet-ID of the Empeg and can thus map a static hostname to it (Regardless of IP address). That's the same way it works for all of you "named" workstations and network nodes.

Okay, I see what you're saying, but let me be more specific.

I format a computer's hard disk and install a fresh copy of Windows. I take the defaults for the network setup, which means it uses DHCP. During the setup, it asks me what the computer's name will be. Let's say I name it "foobar".

After that setup is done, I can walk over to another workstation and type "ping foobar.mycompany.com" and it will work.

I did not have to touch the DNS server to make this happen. In fact, the DNS server isn't even here in our building. It's not even in the same state, it's in Detroit, connected by a frame relay line. Our Cisco router forwards all name server requests and their name servers handle it back at the corporate HQ.

There is some kind of handshaking going on between the workstation and the DNS server which allows the workstation to identify itself by name. The DNS server then assigns the name the workstatation requested. It does all this automatically, without any need to modify the name server's tables of hostnames.

I don't know anything at all about this process, so I don't know how it's done. All I ever see is the end result. But surely there's some kind of a standardized way for this to happen, and it's this standard that Windows is using to get that job done?

There is some kind of handshaking going on between the workstation and the DNS server

Actually from your description, I think this is happening from some kind of Windows protocol voodoo. Like at the WINS or NETBeui level. Try pinging said fresh Windows installation from a non-Windows machine...

So you're saying that the only way to give a Linux computer a network name is to hand-modify a hostname table on the DNS server? There's no protocol for allowing a Linux computer to identify itself on the network? Is that what you're saying? Because if that's true, then what a royal pain in the ass Linux must be to administer.

No. But I know that Windows has quirky proprietary things it uses to keep track of nodes on a network. All sorts of WINS and NetBIOS stuff. If one of these was the guy responsible for you getting your name automagically, then non-Windows workstations wouldn't get it.

However ISTR that when a DHCP lease is requested, you can ask for a hostname to be assigned as well. Like "my network name is COMPUTER and I would like an IP address." Then in addition to giving you an address, the DHCP server would update your DNS entry.

My guess is that the Empeg's DHCP client isn't doing this? Or maybe requires you to put something special in /etc/hosts to make it happen?

However ISTR that when a DHCP lease is requested, you can ask for a hostname to be assigned as well. Like "my network name is COMPUTER and I would like an IP address." Then in addition to giving you an address, the DHCP server would update your DNS entry.

Right, that's all I'm talking about.

My guess is that the Empeg's DHCP client isn't doing this?

Right, that's what I'm saying.

I was wondering if that was a kernel thing, and if so, if Mark could look at it. If it's not a kernel thing, then perhaps I should be hounding the empeg guys.

Are you sure that's not the WINS (WIndows Name Server) coming into play, their proprietary protcol for workgroups? The WINS servers can also then gateway such names to DNS for non-windows boxes to see.

??

My guess is that the Empeg's DHCP client isn't doing this?

Actually, it is. I just checked my DHCP logs from the past few days, and the two new units on the LAN are passing their name off to the server, spaces replaced with dashes.

So Tonys setup is working because of the Windows voodoo magic in WINS or another protocal, and his network does not suppot DDNS (Dynamic DNS) tied into the DHCP server needed to do this on a pure TCP/IP level.

I asked this same question (albeit in a different way) a couple months ago, because our corporate network was being upgraded with a new DHCP/DNS server that would automagically (at DHCP request)update the DNS with the client's hostname. (wow, that's a long sentence)
The empeg answer was that Linux doesn't send its hostname during DHCP req. I never heard that it can't however.

I think he's on about the NetBIOS name.

nmbd from samba can provide this service so installing and running this should do it.

From nmbd man pages.

"nmbd is a server that understands and can reply to NetBIOS over IP name service requests, like those produced by SMBD/CIFS clients such as Windows 95/98, Windows NT and LanManager clients. It also participates in the browsing protocols which make up the Windows "Network Neighborhood" view."

I just installed v107, looks awesome I'm having one problem tho. Some buttons on my remote seem to not work now (i.e. visual, short click menu, and volume). Do I need to set something?

-Dan


....... N/M I should learn to read....

Hi Tony,

What you want to do is to make a reservation for your empeg. Depending on what DHCP-server software you're using you can reserve a DHCP assigned address to a client by defining either it's WINS name (MS style) og MAC address (everyone elses style). Fortunately a MS DHCP server also supports MAC address reservation (it seems)

http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q172408

Now you know that your empeg has the same IP address every time it on a particular network.

Now you can either configure your local DNS-server with a static entry pointing to the empeg, edit the workstations local hosts-file or just use the IP-address directly.

I hope this helps/works.

>I just installed v107, looks awesome.
>Some buttons on my remote seem to not work now
>(i.e. visual, short click menu, and volume).
>Do I need to set something?

Mmmm I have not seen that problem, except for the general beta7 issue where all of the buttons sometimes lock up.

But I did find some other bugs, most specifically one to do with AC/DC power detection: Running kftpd allowed me to browse /proc/empeg_power and there it thought it was on DC when my dock had it on AC.. Ooops. Fixed that one, and a couple other small ones.

Version v108 is now out, the best of the v100+ series thus far. I recommend that everybody upgrade to this number.

Also new in v108, the directory listings from kftpd are now much more complete than before, even to the point of showing symlink targets. But I still get some kftpd lockups (everything is fine if you don't actually connect to kftpd, though), so there's still work to be done there.

 ftp  1.2.3.4  91

(replace 1.2.3.4 with correct IP address).

Hijack v108 is available now from http://empeg-hijack.sourceforge.net

Sorry to be late , couldnt connect on BBS.

I did what ya asked :

Delete line in config ini, sync'ed, off player, restarted and tried
Still no fid display.

Joined a grad of 'serial display'

Finally, a subject about which I can speak with some authority, and I get beaten to it. Auugh!

If your config.ini is correct, then you will see lots of "serial_notify" messages on the serial port while switching between tunes on the player.

If you don't see anything like that on the serial port, then you config.ini is still not correctly set up.

-ml

It is not Wins. It is netbeui over a protocol of you choice, usually TCPIP. Windows assings hostnames also without using wins. Just think that if you setup a home lan without anything but tcpip and netbeui you get hostnames on all computers. You don0t even need DHCP.
BUT I also believed that hostname assignment can be obtained by DHCP servers as well. Was I wrong?

Okay. First, there are two name services involved. One is DNS. The other is Windows' naming service, which can either work in an election mode, or can be served by a WINS server, but is basically the same. Let's ignore Windows clients and servers for the moment. When a DHCP client requests an IP address, it can also request a specific name be assigned as well. Usually, this request is granted. If no hostname request is made, some DHCP servers will make up a hostname, but most will just not return a hostname at all. Many DHCP servers are also set up to pass new DHCP leases along to a DNS server, so that the DNS server gets dynamically updated when a new machine comes on the network. This used to be a very clean way to do this, until Windows 2000 came along. When a Windows 2000 machine gets a DHCP address from its server, it also tries to update its configured DNS server directly (with more info than just the hostname -- I think it's trying to store some Active Directory stuff there as well, but don't quote me on that). This means that the DNS server needs to trust all clients. Most admins (especially non-Windows admins) think that this is an exceptionally bad idea. In reality, most admins have their servers perform as I listed above and ignore those updates from the clients. Windows servers usually have DHCP and DNS (and AD) integrated so that you don't need to do anything to get it to work right (for certain Microsoft-defined values of `right'). Also, Windows clients usually use the Windows nameservice in addition to DNS in order to find clients. This works for even IP-specific utilites like ping.

I think that this clears up most of the questions that were posed, but if it doesn't (and I'm sure that I've left some things out), reply and I'll be happy to clear it up.

Ok, that's what I remembered. So, in theory we may have the empeg request a hostname from ant DHCP sever that supports hostname assignment, right? I think I'll ask Empeg Team whether they think this could be an interesting feature to add in future releases. Empeg's hostname could be user defined via emplode, same as now you can define IP address. It would be awsome if you coluld connect to the empeg via a hostname that does not change with the ip. Expecially now that we have an fto server and a http server in Hijack (Mark, again, you're my hero! ).

So, in theory we may have the empeg request a hostname from ant DHCP sever that supports hostname assignment, right?

Some discussion with Drakino today revealed that the empeg actually already does this. I assumed it didn't because it doesn't work on my network. The truth is that my network only assigns names to windows boxes and ignores the name assignment request from the car player.

The only other thing the car player could do is attempt to do all of that nasty Windows handshaking. Probably not going to happen, as it would be pretty silly.

Then again, maybe it wouldn't be silly if the empeg guys thought it might be important for future networked products. Who knows?

Wow, that's very interesting. Now, what name does the player ask for? It gets ignored on my network as well, fyi. I work on a quite large windows based network, and I am used to refer to machines via their hostname, and just like you I cannot do that with empeg.

The name can be set via Emplode (via the Configure Player dialog). It defaulted (on mine) to ``empegcar''. And I just did some network snoops and determined that it does request a hostname, but I'm too lazy to set my DHCP and DNS servers to do automatic updates.

>if you setup a home lan without anything but tcpip
>and netbeui you get hostnames on all computers.

Funny, I don't. Just the windows box. Everything else (Linux, Solaris, MacOS, FreeBSD, Empeg, etc.. are all excluded from that rather narrow closed protocol. No Good.

-ml

I meant all WINDOWS machines.

As I sad before, you need netbeui over tcpip (or ipx spx, or whatever) protocol, and not (necessarily) wins, which was the point of my post.

I think you mean NetBIOS-over-TCP/IP. NetBEUI (NetBIOS Extended User Interface ) is a non routable protocol and was commonly used for windows workgroups.

You're right. Sorry, I always do that

Upon playing with it more i noticed that in fact all but one of the buttons aren't working. The working button is the long menu press to get into hijack's menu. So it does sound like the beta bug you are talking about. I looked on riocar.org in the FAQ's for something about it and found nothing. How do I get it back to normal?

Thanks!
Dan

Well, that's pretty simple to diagnose, then. You must be using the Hijack kernel on top of a v1.0x release of player software. The two are NOT at all compatible, as noted in several places on the Hijack website. Actually, they are compatible, except that the Empeg guys changed the IR-remote codes from v1.0x to v2.0x.. so the codes the kernel generates --nothing to do with Hijack-- will not work with the older player software.

Either dump Hijack, or upgrade to v2.00beta3 or v2.00beta7 software and then reinsteall Hijack.

-ml

Ok, thanks. I missunderstood how the whole thing worked. I thought the hijack kernel upgrade also upgraded the software. Thanks again!

Dan

I thought the hijack kernel upgrade also upgraded the software.

Okay, this one is going in the FAQ now.