Donna Dionne wrote:
Hi!
One more question. Can I assume that the very 1st ack from server to
client will only contain 1 block, and be length 13? I know that ack
FFFb can have a variable number of blocks depending how many
packets are being acked as each sequence number will take up a blo
Hi! One more question. Can I assume that the very 1st ack from server to client will only contain 1 block, and be length 13? I know that ack FFFb can have a variable number of blocks depending how many packets are being acked as each sequence number will take up a block. But the very 1st fr
Jesse Nesbitt wrote:
On 10/17/06, Donna Dionne <[EMAIL PROTECTED]> wrote:
Hi!
A few more questions:
1. During the XML-RPC login, server will send a "server hello" to the
client
and there is a certificate embedded in the TLS handshake protocol.
Is this certificate ever encrypted?
Is this cert
On 10/17/06, Donna Dionne <[EMAIL PROTECTED]> wrote:
Hi!
A few more questions:
1. During the XML-RPC login, server will send a "server hello" to the client
and there is a certificate embedded in the TLS handshake protocol.
Is this certificate ever encrypted?
Is this certificate generated for ev
Hi! A few more questions: 1. During the XML-RPC login, server will send a "server hello" to the client and there is a certificate embedded in the TLS handshake protocol. Is this certificate ever encrypted? Is this certificate generated for every session? can it be stored and replayed? 2
John Hurliman <[EMAIL PROTECTED]> wrote:Donna Dionne wrote:> HI John,> > Just confirming about the zero encoding.> > Because the packet id cannot be 0, zero encoding will not affect > fixed, medium, or high packet headers.> > For low packets wehre the packet id can be 2 bytes, the 1st byte coul
Donna Dionne wrote:
HI John,
Just confirming about the zero encoding.
Because the packet id cannot be 0, zero encoding will not affect
fixed, medium, or high packet headers.
For low packets wehre the packet id can be 2 bytes, the 1st byte could
be 0. And if zero encoding is used, i.e., o
HI John, Just confirming about the zero encoding. Because the packet id cannot be 0, zero encoding will not affect fixed, medium, or high packet headers. For low packets wehre the packet id can be 2 bytes, the 1st byte could be 0. And if zero encoding is used, i.e., opcode 0x80, and pa
Austin Jennings wrote:
Here's the one Decoder uses:
- traffic is to or from *.lindenlab.com
Not perfect, but it works pretty well :)
you win.
___
libsecondlife-dev mailing list
libsecondlife-dev@gna.org
https://mail.gna.org/listinfo/libse
Here's the one Decoder uses:
- traffic is to or from *.lindenlab.com
Not perfect, but it works pretty well :)
On 2006/10/12, at 20:02, John Hurliman wrote:
If you are just trying to determine whether network traffic is
Second Life traffic or not, here are some heuristics you can use:
*
If you are just trying to determine whether network traffic is Second
Life traffic or not, here are some heuristics you can use:
* The server UDP port will be either 12035 or 1300 to 1350 as Phoenix
said. 12036 as well?
* The first byte of the UDP payload is the flags field. There are only
Ok, I lied a little bit about the first UDP communication. See
comments in-line.
On 2006 Oct 12, at 10:30, Donna Dionne wrote:
1. a fix packet fffa from client to server
a fix packet from server to client
a fix packet fffb from server to client
a fix packet ff
HI! Thanks so much for the explaination... Could someone explain to me the sequence of events during a session. From my capture, I see that the 1st UDP packet is the UseCircuitCode; however, there were some activities prior to the 1st UDP packet to some other servers in the subnet: 1.
The signature for our protocol is probably not super-easy to detect.
The first UDP packet will always be a UseCircuitCode from the viewer
to the simulator. The viewer usually binds to an ephemeral port. The
simulators are always bound to either 12035 or 1300 to 1350.
Sadly, those funny numb
SL's not set up as a totaly traditional client-server system. LL hosts
the Simulator, a server that hosts the Region that you're in and all
its objects. The Viewer is the client that you use to access Second
Life, be it the original or libsl-based.
As far as I can tell (and from what some Linden
HI! Thanks so much for the reply! I am a bit confused about the terminology used here. Can you correct me about my understanding below? viewer = client simulator = server viewer = game site ? simulator = subscriber/user site? 1st packet is from client to server server typcial
Donna Dionne wrote:
HI!
From some captures we have, it looks like the 1st packet from the
server to client has the following header
40 00 00 01 FF FF 00 03 and the total size of the packet (header and
payload) is 44.
This seems to indicate this is a UseCircuitCode packet, with the
followin
HI! From some captures we have, it looks like the 1st packet from the server to client has the following header 40 00 00 01 FF FF 00 03 and the total size of the packet (header and payload) is 44. This seems to indicate this is a UseCircuitCode packet, with the following fields (in order)
18 matches
Mail list logo
