Does they have iKVM support schedule?

[NorihisaNakai]

Hi, We want to connect to iKVM (Supermicro motherboard IPMI VNC Server) on noVNC. But, iKVM VNC protocol use original future on VNC protocol. if project have to support iKVM, would you tell me schedule?

Thank you for your cooperation.

Norihisa Nakai

[disaster123]

Great! So i can just check out https://github.com/kelleyk/noVNC/tree/ast2100-support and connect to the IPMI url of my servers using the IPMI password?

[kelleyk]

@subv3rsion Glad to hear that it's working for you! I had a similar reaction to their client, which is what inspired the project.

@disaster123 Yes, it's almost that simple! You'll need to use websockify (like you normally would with noVNC), but if you point websockify at the IP/hostname of the BMC and then enter your IPMI USERNAME:PASSWORD (separated by a colon) as your noVNC password, it should "just work".

[disaster123]

@kelleyk it works great and speed at least for server console is really fast enough. It's just very difficult to read the text. It seems some pixels are missing.

[disaster123]

@subv3rsion what have you done to get that nice picture quality? Have you changed it via atenChangeVideoSettings?

[disaster123]

sorry for tripple posting. Is there any way to get the correct keyboard layout? (i'm in germany here but layout is US)

[subtato]

I have not changed anything, I simply cloned the repo, started the websockify server, and connected over our internal VPN. There are some troubles on our end with the display as you've mentioned, but Kevin did warn of some quality issues upon his commits being made / his comment here.

I'm not familiar enough with the noVNC project to answer your other question, unfortunately. I'm certainly working on it though :-)

[disaster123]

ah OK my screen looks only good if i send the mentioned command through console.

[phil21]

It's exciting to see this come along so well. We've been working on getting some basic testing going, and I started a google docs spreadsheet to track it. If you don't mind testing your hardware, noting the mothboard model, firmware revision, and any testing notes we would certainly appreciate it! I'll make sure they make it in.

https://docs.google.com/spreadsheets/d/1wVrwOpebTn43ncEBY9dfn1SMVM205NEMwy1W8q_kR3s/edit?usp=sharing

If anyone wants to help maintain that simply request editing privileges, otherwise I can also convert to a .md for collaboration.

@alantwentyseven will be merging his work with @kelleyk and hopefully there will be one solid branch to test from for all "iKVM" support. They can certainly explain those plans better than I.

Still a lot of cleanup work to do, but I'm excited! We'll continue to test on our end as well.

[disaster123]

Just tested an X10SRi-F works fine too. Firmware Revision : 01.67

[subtato]

Working:

• X10SLM-F / 1.07, 1.35
• X10SLE-F / 1.23
• X10SLD-F / 1.07 (previously mentioned), 1.23, 1.85

Not working:

• X9SRD-F / 3.19 (hangs on "Authenticating using scheme: 16", both valid/invalid details)
• X10SLE-F / 2.19 (passes the above error, results in "no supported sub-auth types!")

I'll try some more systems as I find the different models and IPMI versions we have available. I haven't tried anything different regarding the two unsuccessful attempts, which may simply be some simple configuration change during the upgrades.

[phil21]

I've updated the spreadsheet a little to be a bit more clear, for now I'm adding github reports to the bottom in the order as they come in. As things stabilize a little I'll start sorting them into the proper product categories.

I think there may be a regression in 0x59 (X9/WPCM450) support, as some very similar systems to those previously tested no longer work. Unfortunately I don't have direct access to a X9 based machine immediately.

If you don't mind testing the original branch of https://github.com/jimdigriz/noVNC/tree/aten-ikvm with the X9SRD-F that'd be quite handy.

X10SLE-F not working surprises me, I saw a similar error earlier in testing today but it was due to not switching to the proper branch :)

Edit: Also if anyone is working on this and wants to chat, we have an IRC channel on freenode we coordinate in: #killjavawithfire should anyone be interested in some more real-time communication.

[subtato]

@phil21 Same result for the X9SRD-F using the aten-ikvm branch you've specified.

In regards to the X10SLE-F, I've double checked that I'm on the right branch, only difference is I had been 2 commits behind. Honestly, it kind of surprised me too. Firmware 2.19 seems to have additional features that I haven't seen in other firmwares from Supermicro (or even on 1.23), such as a license feature to maintain BIOS updates/RAID, "SUM licensed checking", and some smaller tweaks in many other places.

[kelleyk]

The "SuperMicro Update Manager (SUM) licensed checking" thing might be poorly explained, but it's just a reference to the same BIOS feature license. Some of their tools can collect the machines' MAC addresses; you send them in, pay the per-board licensing fee, and then their tools can automatically send the right license key to each machine you paid for.

Also, in regards to a possible regression in X9 support (for those boards using 0x59 / "ATEN_HERMON" encoding): I will confess to not actually testing against an X9 machine, but the only change I intended to the existing 0x59 code was to rename it from "ATEN" to "ATEN_HERMON" and to remove a warning about 0x57 being unsupported.

[alantwentyseven]

I found the issue with the 0x59 regression; to do with the ATEN auth code. Will speak to @kelleyk to get the correct fix to this today. I will also be submitting a pull-request to include the OpenVNC (IDRAC / Dell) support, so we can have as much support as possible in 1 branch. Watch this space!

[kelleyk]

Yep - as @alantwentyseven discovered, the #445 pull request (in which @DirectXMan12 rebased @jimdigriz's work on master) only got two of the three commits on @jimdigriz's aten-ikvm branch. The missing commit (https://github.com/kanaka/noVNC/commit/93fabe9080c0dfc3d0a0874f6237ae33f43c7a62) relaxes the heuristic that is used to differentiate an ATEN iKVM server from one that is actually using the (legacy) "tight" security type (16).

I'm going to go push the same change to my ast2100-support branch.

I took a quick peek, and there is not any "black magic" inside the ATEN client's handshaking/authentication code. Therefore, I would suspect that if there are any boards that still don't work with this tweak (and especially if noVNC fails with an error about security type 16), that we will simply need to improve the detection heuristic a little bit more.

[kelleyk]

Hm, that's odd. It looks like I wasn't quite right: it looks like we somehow wound up with one of the constants from before that commit and one of the constants from after that commit... which doesn't seem like it would work at all. (Makes sense: that's why all of the earlier-generation boards are not working.)

If you've had that sort of trouble, please pull from my ast2100-support branch and try again. I promise I didn't change anything related to 0x59 support; there should be no impact to that functionality!

[phil21]

We've been testing out of @kelleyk's https://github.com/kelleyk/noVNC/tree/bmc-support branch tonight, and with promising results. This is as close to a "one branch to rule them all" for BMC support that there is. Various Supermicro X8/X9/X10 and Dell iDrac7 and iDrac8 have been confirmed to work. There is still work to do to figure out why some other seemingly very similar systems/firmware combos are failing.

First, those who previously tested X8/X9 based boards and had a failure, can you please re-test w/ the branch above and note results? We expect at least some of them to now work. Also @subv3rsion I would be interested to know if the X10SLE-F continues to fail.

Also, if you have the capability to generate a packet capture of the TCP session to the BMC that would be very helpful at this point as well. The first 40 packets of simply connecting and authenticating is fine, instructions for the tcpdump are in the README:

https://github.com/ServerCentral/bmc-pcap

Submit a pull request and I'll add yours.

I think that covers it for updates. This has been fun and exciting seeing it coming together, and the test reports are extremely helpful! Keep em coming.

Support matrix updated with latest: https://docs.google.com/spreadsheets/d/1wVrwOpebTn43ncEBY9dfn1SMVM205NEMwy1W8q_kR3s/edit?usp=sharing

[disaster123]

Has anybody a workaround for foreign keyboards in novnc. The IPMI always expects an english one.

[markuspf]

Oh my god people, I just checked back here and found my two Supermicro (X10 series) boards to work with @kelleyk's branch. This is so awesome, finally no booting windows just to fix me messing up boot. Thank you so very much!

[kelleyk]

@markuspf I'm very happy that you're enjoying the AST2100 support!

@disaster123 I'm afraid that I don't know very much about foreign-keyboard support (as far as noVNC is concerned, at least). This sounds like something better discussed as part of #21.

[kelleyk]

For everyone else: I'm sorry that progress has stalled a bit here. @alantwentyseven has contributed an implementation of some UI controls for the AST2100 video settings; when I have a few moments, I intend to merge those into my bmc-support branch, make some fixes to the heuristic that we use to detect when we are speaking to an ATEN iKVM server, and then clean up the code and touch base with the core noVNC maintainers about what sort of pull request they'd consider merging into mainline.

I also have a half-baked series of articles describing my adventures in reverse-engineering the video encoding and explaining in more detail how it works.

Please speak up if you have any particular interest in this functionality (unless you're one of the ladies/gents I've been in touch with out-of-band).

[disaster123]

great and thanks!

[williamsjj]

Using the bmc-support branch I'm not able to log into a SuperMicro X8SIE. Here's a screencast of the login attempt:

http://www.screencast.com/t/uEdTlZY7u

[kelleyk]

@williamsjj Thanks, I'll put that on the list. (Just to confirm: that board uses ATEN firmware, not AMI firmware, right?) It would be a huge help if you could pcap the initial handshake (with noVNC is fine, or even better if you use one of the official clients that can actually connect). We only need the first couple of packets; take a peek at the great stuff that @phil21 has spearheaded over here: https://github.com/ServerCentral/bmc-pcap

We use those captures for compatibility testing. I'm sure he would love a pull request!

As a general status update, I've done all of the work I mentioned above except for fixing the heuristic that we use to detect whether or not a VNC server is actually an ATEN iKVM server. (It should work for the majority of boards, though.) I've just been puttering around on fixing that (really a tiny amount of work, though adding good testing for it is a bit harder) and will try to finish it up shortly.

[andriishestakov]

Hey guys! Have you any success with AST2400? I have following server: SuperServer 6018R-TDW Motherboard Supermicro X10DDW-i rev. 1.10 Firmware Revision : 02.15 noVNC hangs on step: Authenticating using scheme: 16

[sodabrew]

@andreyshestakov If you can get a tcpdump of the VNC session and submit it to https://github.com/ServerCentral/bmc-pcap that will help. Please make sure you are actually using noVNC from https://github.com/kelleyk/noVNC/tree/bmc-support for testing with your IPMI controller.

[kelleyk]

Thanks @sodabrew -- that's exactly the best way to help. it probably doesn't actually matter which VNC client you use (or whether the connection attempt succeeds); we just need to see the first couple of values that the iKVM server sends.

I know that this project has sort of been sitting here for weeks and weeks; thank you all for your patience. I'm trying hard to find the couple of hours I need to just sit down and crank out something that should be a longer-term solution.

Note that the AST2400 BMCs are members of the "AST2100 family" and should be supported as long as they're running the ATEN firmware (which SuperMicro sometimes calls "SMT" on their website). Some older machines (X7/X8, mostly, I think) used AMI firmware and that is not supported. (It wouldn't be impossible, but it's different.)

[kelleyk]

Okay; I've pushed a very minor tweak to the heuristic that we were using to detect iKVM servers. Please try with the latest from my bmc-support branch and let me know if you have any trouble.

We're expecting this to work with all SuperMicro boards with ATEN firmware and AST2400 (AST2100-family) BMCs.

[kelleyk]

Just as a reminder, reports that the latest version fixes your problem will be much appreciated!

[naterh]

Is this suppose to be working with Intel AMT as well? Didn't see any platforms using it in the xls but there has been references to it in rfb.js for some time.

[kelleyk]

I haven't done any work on Intel AMT, so if main-line noVNC doesn't support it, this branch won't either. If there is interest in having it supported, we could talk about that.

It seems that there is support integrated into RealVNC, but I haven't done any digging on whether or not the underlying protocols are publicly documented or whether it'd be a reverse-engineering project. The latter would, naturally, be more fun.

[kelleyk]

Looks like there's an SDK (https://software.intel.com/en-us/amt-sdk/download) and documentation (https://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide/default.htm) available (though I haven't actually looked through any of it), so perhaps it would just be a matter of implementation.

Then again, according to http://blog.michael.kuron-germany.de/2011/10/using-intel-amts-vnc-server/, with the proper configuration, you should be able to use any standard VNC client (including noVNC) to connect to an AMT server.

[naterh]

We also have racks of hw that use Avocent kvm on AST2400's. I'm sure that could be fun too. We've already asked to get it switched out but, diversity is nice 👍

[kelleyk]

I'm not sure what you're saying. The original aim of this work was to support AST2400-based SuperMicro gear, and since the video encoding is hardware-based, there can't be much more work to do to support other AST2400-based gear, too.

What sort of Avocent AST2400 KVMs are you using? Are they internal to or external to the machines?

Why have you asked to replace them? Is it because of the KVM situation?

[naterh]

Here's some more info on the Avocent kvm. https://gist.github.com/naterh/af75133166c13721afe6e999f3f9f9fe https://gist.github.com/naterh/13e4ac685e98cd385bea0f476fd767de The ATEN kvm's we have on some of our Quanta platforms appear to be using ATEN AMI and I've had somewhat promising results so far. I have not had much success with the Avocent KVM's yet though and both are using AST2400 controllers.

I like what your getting at though and if true, platform independent could also mean OpenBMC kvm over ip support on say OpenPower systems which would be 💯

[dschlenk]

@kelleyk I tried a X10SLL-F with latest bmc-support branch and I get

ATEN iKVM credentials required (user:password) -- got only

when I don't specify a password, and then

No supported sub-auth types!

if I do. Is that a known issue with AST2400-based things? Or am I doing something wrong? Started with:

./utils/launch.sh --vnc <IP_ADDR>:5900

EDIT: sent a PR with a pcap.

[frovik]

Hi Guys,

It is worth mentioning that supermicro actually has released firmware support html 5 on some motherboards.

X10DRW-i X10DRW-iT

with firmware release 3.32 adds html 5.

Now while I dont recommend bricking your motherboards this should in theory work for most X10 motherboards.

See also:

http://www.supermicro.com/support/faqs/faq.cfm?faq=22571 http://www.supermicro.com/support/faqs/faq.cfm?faq=22376

[kelleyk]

@dschlenk Thank you for the report and the PR! I'll look at it when I have a second.

[kelleyk]

Hm, odd. From your packet capture, the handshake looks like this

    00000000  52 46 42 20 30 30 33 2e  30 30 38 0a             RFB 003. 008.
00000000  52 46 42 20 30 30 33 2e  30 30 38 0a             RFB 003. 008.
    0000000C  01 10                                            ..
0000000C  10                                               .
    0000000E  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 ........ ........
    0000001E  00 00 00 00 00 00 00 00                          ........ 

In the first two lines, client and server report supporting RFB protocol version 3.8; then, the server tells the client that it only supports one authentication type (number 0x10, which is tight, but also what the ATEN iKVM daemons advertise). The client tells the server that it has selected 0x10, and the server replies with a bunch of zeroes.

We'd have expected this to work. On the relevant line of code, you should see numTunnels == 0 and this._rfb_server_supported_security_types == [0x10], so _negotiate_aten_auth() should be called.

Just to make sure: what are you putting in the noVNC password field? It should be username:password (e.g. ADMIN:ADMIN for the default username and password). (This is just how the existing ATEN code worked when I came along.)

[kelleyk]

Let me apologize in advance if you have wasted any time trying to figure out what you were doing wrong. The current bmc-support branch is broken. Fixes should be along shortly.

[kelleyk]

And presto!

The current bmc-support branch should pass all tests, both old and new; we even fixed a bug (a global leak) that's present upstream! (Just npm install and then node tests/run_in_console.js to run the suite.)

I've also quickly tested against an X10SLM machine and it seems to work as expected in practice, too. (More real-world testing will follow, probably in the next few days.) Have at it!

@DirectXMan12 When you have a second, I'd love to chat about the possibly of merging this work into mainline noVNC.

[kelleyk]

As a heads-up, I have now rebased my bmc-support branch against upstream master.

[bobobo1618]

Using kelleyk's branch on an X10SDV-F-O I'm getting weird display issues that look like this:

For reference, the Java client looks like this:

[bobobo1618]

Ah, it appears the issue is that the issue is the 4:2:0 chroma subsampling setting. Turning on 4:4:4 makes it look fine again.

[kelleyk]

Yes, I'm aware of this issue (but thank you for reporting it nonetheless!). I've been meaning to track down the difference between my implementation and the official client's, but haven't had a moment to take a look. In the meantime, you found the workaround!

I suspect that this isn't actually a bug with subsampling. When subsampling is on, the iKVM server only sends JPEG-like data; when subsampling is disabled, it can choose between smaller blocks of JPEG-like data or color quantization, which it (reasonably) seems to prefer in situations where there are few colors on screen (as in your screenshots). I bet that the quality improvement is actually that it stops sending JPEG data at all.

[bobobo1618]

That would make sense. Perhaps the spatial subsampling is intended more for previews and such like those shown on the IPMI homepage rather than actual view/control?

Also I have a feeling it's out of scope for noVNC but is it likely that we'll get virtual media, power control and such at some point?

[kelleyk]

No, it's definitely a bug in my implementation. The JPEG-type compression is a general solution (i.e. it can represent any image); the subsampling is likely to reduce the amount of bandwidth required. The quantization probably got tacked on because they imagined people might spend a lot of time looking at the BIOS, terminals, and that sort of thing.

The remote media is definitely out of scope for noVNC, but it'd be an interesting project!

[bdrung]

@kelleyk Can you rebase your bmc-support branch against upstream master? I like to test the keyboard layout changes done upstream with your bmc-support branch.

The bmc-support branch works quite well. It sometimes shows a code 400 like

127.0.0.1 - - [12/Sep/2016 17:24:33] code 400, message Bad HTTP/0.9 request type ('\x88\x8f\x9c\xb2E+\x9fZ\x11J\xee\xd5')
127.0.0.1 - - [14/Sep/2016 16:48:35] code 400, message Bad request syntax ('\x88\x8f\xa2\xb7\xdb0\xa1_\x8fQ\xd0\xd0\xbeD\x82\xd4\xb7_\xd1\xd2\xbf')
127.0.0.1 - - [14/Sep/2016 16:48:35] code 400, message Bad request syntax ('\x88\x8f\xa2\xb7\xdb0\xa1_\x8fQ\xd0\xd0\xbeD\x82\xd4\xb7_\xd1\xd2\xbf')
127.0.0.1 - - [14/Sep/2016 16:52:49] code 400, message Bad request syntax ('\x88\x8f\xa1\xd8\x8d\xc9\xa20\xd9\xa8\xd3\xbf\xe8\xbd\x81\xbb\xe1\xa6\xd2\xbd\xe9')

This seems to happen when the screen resizes.

[influenist]

Interesting topic lads! Great work so far @kelleyk, appreciate the work that has been done.

I was wondering, are all the files in the dirs /include and /utils used or can we strip this down?

Also, has this been tested against the x11 series yet? We might have also some x7 ATOM series in production which we can test it at. I know a lot of folks had these as home servers in the past. Let me know if you need any help on this.

[phil21]

@influenist X11 has been tested on a very basic level due to lack of test gear. As far as we are aware the entire series should work though.

The X7 board will not work, due to it using an entirely different protocol. Generally speaking most (but not all) X9 servers are supported, all of the X10 lineup, and in theory all of X11. There are some X8 models that should work as well, but not many. See the google docs spreadsheet linked earlier.