Paging DrO

[Smelter]

Hey,

So Im going over the new ultravox framing and stuff for broadcasters.

2 things...

When it says to send the version in the cipher request, it doesnt say what format that '2.1.' is supposed to be in.

Second is the description of the frame format in that particular table is not easy the first time around.

Explicitly describe the version payload format. and "[16 bit msg length - first half] [16 bit msg length - second half]" makes it sound like 32 bit payload length. The header row of the table confuses one to think if the numbers are the item or the byte position.

Can you give a hand in the language of your choice , to show anything about framing ? Is there a simple method that you can show a serialization into a byte array?

I believe my bitstream writer may be outputting the 4/12 bit combination in byte order 4-3 instead of 3-4. I think Im accidentally writing the first 4 bits in the low. Im goina try putting the 4 bits in the high, followed by 12 bits. NSV bit encoding was opposite.

[Smelter]

looks like it..

now at least Im getting the ACK:foobar

[Smelter]

code:


		frameHeader[0]=SYNC_BYTE;

		frameHeader[1]= getQos();

		frameHeader[2]=(byte) (( classType<<4) | (messageType>>8) );

		frameHeader[3]=(byte)( messageType & 0xFF);

[DrO]

#1 - "2.1\0" is the string passed.

#2 - to create parts of the frame, we're using htons(..) to get the correct byte order and ntohs(..) to get from the sent byte order back to what's appropriate for the platform.


i'll look over anything else from your posts properly tomorrow / tuesday so i can just make edits to the wiki in one go (as i've something else to amend on there already which i forgot to do this week).

[Smelter]

Try vertical. I like how adobe did theirs.

code:




UI* =unsigned integer * bits long.



UB* unsigned bit value * length.



Ultravox Data Packet



sync byte	- UI8     - Always 0x5A



Reserved	- UB[4]    - 0x0



QoS_A 		- UB[1] 	- 0= Can be dropped, 1= Critical packet. 

QoS_B 		- UB[3] 	- Relative priority of this packet.







Message Class	- UB[4] 	- See message class table.



Message Type	- UB[12] 	- See subclass type tables.



Payload Length	- UI16		- In network byte order.



Payload 	- UI8[n]	- Payload data.



Termination	- UI8		- 0x0 Frame terminator.



Seeking to '0x0,0x5a' may yeild a frame.	

[Smelter]

Let the developer derive and manually count the structure out rather than break it down by byte by byte.

Unless you do that ugly RFC style with 32 bits per line and boxes ....

[DrO]

looking back at things, it does state that the values use network byte order, though i guess i can better clarify that. plus the "2.1\0" part is mentioned, though the formatting of the text doesn't help.

[Smelter]

Thanks, Dr, I think its mostly that its not a regular notation Ive used before.
Horizontal layouts are done in strict 32 bit rows with each bit colored in with what it is.

Normally I read vertical ones. The horizontal ones are only seen in RFC like below.

Your table doesnt fit the bill. Its really confusing to an 'old Pro' (read old dog) like me.
Your top header row is neither byte positions or item index. Item 3 and 4 combine, and 5 is split. One cannot dedeuce without working it out manually.

The issue is 'room for error' in its current form.


Horizontall style is ugly.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| defined by profile | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| header extension |
| .... |

[Smelter]

Today Im goina attempt to cipher the password and maybe try settup too!

Im having a blast.

Thanks again DrO!

Excited because jelly bean comes with hardware coder access without going full native OMX in c++

[DrO]

the general format is what was available when i took on things and as there's not been any feedback, had to assume it was ok. will take on board the comments and make some adjustments to things.

[Smelter]

yup, there is always a story how code got to where it is.

[Smelter]

Got another question.

Im looking at. "<Version>:<SID>:<UID>:<AuthBlob>"

Where does the auth blob come from. THe auth hash in byte form?

[Smelter]

is the auth blob the entire message digest?

[Smelter]

there are a couple of good diagrams for the header layout here

http://hackipedia.org/Protocols/Inte...col%20spec.pdf

Im goina try just xtea encoding username and password.

Talk to ya later! thanks again!

If this doesnt work tonight, Ill just play with legacy mode.

[Smelter]

guess Im stuck using legacy auth.

First of all, insider resources,JKey's Library for making the auth blob refuses to link with any of my compiler tools. Or Im just an idiot.

Following the wiki exactly , including the c++ code can make a cipher that does indeed encrypt and decrypt however, I only ever get a NAK:2.1eny from the server.

Studying further every available doc, including privileged information I have, does not specify anything more.

Either I am doing something stoopidly wrong with c++ or the idea that uvox2.1 is open for making my own publishing tools is a laugh.

Using the code from _the_wiki_ I get this result.
user: andy pw: changeme

code:


"2.1:1:504933160941eb02:dc1981ad4d432986\0"

Unless I missed a page that said, "format your auth blob by appending X,Y,and Z" I assume I am XTEA coding as 'userassword'.

So yea, unless someone comes clean, or JKey comes back around with some pointers, Im in the same boat as every other independent.



Did I seriously just miss a page on the wiki, or has the format of the auth blob been rendered 'top secret'? I am NOT talking about the stream-HASH, Im talking about the supposedly documented ultravox authentication request message.

code:




Message Class – 0x1

 Message Type – 0x001

 Payload – <Version>:<SID>:<UID>:<AuthBlob><NUL>

 <Version> - protocol version number (required, numeric, non-zero, maximum 255).  The current version is 2.1.

 <SID> - stream identifier (required, numeric, non-zero, maximum 2147483647).

 <UID> - user identifier (required, XTEA encoded).

 <AuthBlob> - authentication information (required, XTEA encoded).

 <NUL> - ASCII 0x00

did I mention boo hoo?

[DrO]

[rant]
you're being melodramatic as others have implemented support based on that without input from us. sure the layout isn't how you like it but that's all there was and that's what i put up as funnily enough there aren't countless free hours to make everything all nice for everyone's different needs. and as things have now changed, i don't have the time to review the page (yes i said i would but hey ho that's what you get) so it's back on the bottom of the todo list as getting a newer DNAS (and everything else being worked on be it SHOUTcast or Winamp) out the door is more beneficial than doing that sort of doc update.
[/rant]


the format of the auth string is (spaces added to make it clearer):

2.1 : 1 (or the desired stream id) : <XTEA_username> : <XTEA_password>

with the username being optional in most cases unless connecting as a v2 DJ to sc_trans (or something like it with DJ support). though it's possible the DNAS will also refuse the connection if that is specified with the current build (but is changed in the next release since we can make use of it instead of some of the legacy aim, irc fields).

[Smelter]

THanks DrO.

That is the only thing I wanted to know. What the hell was an 'Auth blob'.

Confirming that the 'Auth blob'= xtea password and not an amalgamation is a positive step.

If I use the wiki, xtea encoding 'andy' with 'foobar' yields 504933160941eb02 . It decodes into 'andy' just fine, yet the sc_serv rejects with 'bad password' so then Im doing something stoooopid with c++.

You have been a great help. Can you tell what I did wrong in your environment to produce '504933160941eb02' for 'andy' ? im using the xtea wiki code, and that is the std::string it produces.

Thanks again. If I can join the wiki I'll update the patern descriptors. Its very close to what my doc has but enough of a difference.

Didnt mean to piss ya off, just pointing out my own frustrations at my attempts to pick up uvox protocol. defining auth blob , is a big deal. I realize that it takes different forms for different protocols.

[Smelter]

Im using this ecoder model and getting dif results. http://code.google.com/p/h2database/...rity/XTEA.java

Ill try it with the uvox frame

[Smelter]

Of course it was my own lack of c++ luster. Sorry to rile ya up. Thanks again.

my own error...

SIGNED 32 bit int where UNSIGNED is required. I KNEW! it was me.

[Smelter]

once I fixed the unsigned issue, I am able to build an android library for making the blob.

Thanks again! It wasnt till I had confirmation on the format that I could really look over my testing.

[DrO]

at what part had you mixed up signed vs unsigned ?

[Smelter]

stooopid me on the typdef for __uint32

[Jkey]

Originally Posted by Smelter

First of all, insider resources,JKey's Library for making the auth blob refuses to link with any of my compiler tools. Or Im just an idiot.

Stumbled across this thread on google while trying to recover docs I have long
since deleted.

I appologise smelter. If I could have given you the source to my Auth21 lib at the time
I would have. It ended up in the DSP Plugin, so it became the property of AOL.
[ Even though it was not covered by a NDA at the time ]