Logging on a Linux host

[jimbo123]

Just having a play around with logging and the like and am curious at what's involved in reading the logs without one of those z80 specials.

The aim is to read logs dished out by a Dream on a remote Linux box.

Is it possible to point netcat to a Dream's log port and pipe the input into dvbsnooper and come up with meaningful information ? Are there alternate tools around for that could be used ?

I've done the above but just seem to get the same data over and over again.

Any information would be much appreciated.

Thanks,

Jim.....

[ilikethat]

If I had a copy of that new logger I could convert it to linux if anyone wants to post a copy for me.

[z80]

how many times you gunna post the gimmeee gimmeee ?

No one knows what you're talking about here.

[ilikethat]

Removed , dont push it - Sanity


the thread says logging on a Linux host all Im offering is to convert it to a linux app to run native in the host.

[crypto7]

If you want to develope something for a linux box that gets its data of a dream/mlog server what you need to do is...
1. Create a tcp connection to the logging server (mlog) on the correct port eg 31338
2. Send a http style request
eg...
GET /CA_PID HTTP/1.1\r\n
Host: Host\r\n
Accept: text/html, */*\r\n
User-Agent: Mozilla/3.0 (compatible\r\n <-- Note simily face sould be ; ) without the space
\r\n

where CA_PID is the EMM set you want to get (stb needs to be tuned to a valid channel
Host should be the calling host and
\r\n is the cr lf (0x0D x0A)
Then you will get a reply... then you will get the data....
The data will be the DVB 184 byte blocks... and Yes I do mean 184 it is missing the header bytes...
You then need to work out how to parse that into the correct EMM packets...

[jimbo123]

Excellent stuff crypto.

Gives me a start.

[jimbo123]

Hey crypto,

Any chance of looking at the data.txt file uploaded and letting me know if that stuff looks like what's expected. I can see separator 8240,.. also other patterns,.. ff fillers followed by 00,.. as per .. I think its right,.. just want to confirm.

Thanks again,

Jim.....

[crypto7]

The HTTP/1.1 looks look. With the reply ignore everything until
\r\n\r\n (ie: that will mean the Server:.... line \r\n then a blank line \r\n

I assume the jibberish at the start of the next line was the date befor you started to convert to hex.

So try something like
Send Connection HTTP Request
read byte by byte from the stream until you get \r\n\r\n
then loop while reading 184 bytes at a time. Dump those to a log file/screen and you will have a column of 184 bytes (ie append a text formating EOL).

Once you have doen that you should start to see whats going on. Since you are giving it a go, here is the next little pointer (that should help once you start looking at the column of data).

Note: you will be missing the header bytes. One of the bits in the header was a flag that would tell you what the first byte of each 184 byte data block was. We dont have that so need to check and work it out.

The first byte of each 184 byte block will be either
a) the offset to the Start of the next packet (ie: it will point to the seperator). ..... So Must Not be added to the EMM
or
b) if there is only the completion of the previos EMM, and no other data in that packet the first byte will be DATA and Must be included in the packet.

is the 008240 you saw would have been a good place to start and sync from

ie:
00 The next EMM starts at 00 bytes from here.
8240 Emm header (what we all call the seperator).

Some streams will allow the EMMs to go over mulit packets, while others dont do it.
So again make the 184 byte hex colums where you drop all data unitl the 008240 (in your example) so sync to at it should start to fall into place.

[jimbo123]

Thanks again for all the information you've provided.

Looks like I'm heading the right way,.. which gives me a bit of confidence

Yes,.. jibberish before the looping/converting.