Open GoogleCodeExporter opened 8 years ago
Here is the log file...
Original comment by MichaelA...@gmail.com
on 1 Mar 2010 at 9:19
Attachments:
If you're seeing "Corrupt video stream", then that means the PS3 has detected
the MAC
address is incorrect somehow and starts to poison the video stream.
If you are sure the MAC address is correct, then this probably means that the
PS3 is
also checking the first three octets of the address and comparing it against a
list
that is registered to Sony.
For example, enter the first three octets (ex: 00:01:4a) of a MAC address here:
http://www.coffer.com/mac_find/?string=00%3A01%3A4a
This is not a defect of Open Remote Play.
Original comment by darryl...@gmail.com
on 7 Mar 2010 at 4:11
Thank you for the reply.
I am confused however as to how the psp is able to use the mac address of the
pc (a
non-Sony mac). If indeed remote play checks the first three octets, shouldn't
the psp
using an incorrect mac receive a corrupt video stream as well?
Original comment by MichaelA...@gmail.com
on 7 Mar 2010 at 11:18
Yes! I didn't think of that. If you are able to use the PSP with a spoofed
MAC (of
your PC) and it works longer than a few minutes without errors or corrupted
video
frames, then scrap my previous theory - obviously this fact disproves it.
Are you running a Linux gateway or are you able to run Wireshark on your
network and
capture traffic originating or destined for your PS3? I would be very curious
to see
two captures. The first being between your hacked PSP (with spoofed PC MAC)
and your
PS3. The second being from ORP and your PS3 - resulting in a corrupt video
stream error.
Specifically I would like to examine the Ethernet frame headers between the
two.
Both sessions should have identical source/dest. MAC addresses. If not, then
that
would be the point to debug from. If they are identical, then WOW - Sony must
have
come up with some freaky way to detect ORP that we're unaware of. However, I'm
able
to use ORP just fine with the latest PS3 firmware, so I suspect the latter.
So at this point, I'm not sure how technical you are or even if you have the
time/interest to debug further, but the next step would be to start dumping
network
traffic and using Wireshark to analyze the Ethernet frame headers.
Reverse-engineering is a dirty business :)
Original comment by darryl...@gmail.com
on 8 Mar 2010 at 4:01
Well at the moment i don't have tons of time but spring break starts on friday
for
me. So at that point i can dedicate a lot of time.
I got wireshark running on my pc and played around with it for a little bit.
i've
recorded traffic from my pc to the ps3 while launching orp. I haven't quite
figured
out how to filter out the other junk that wire shark is recording.
I don't know how to use wireshark to record the psp's network activity. It's not
showing up on the log when i run it.
I believe my router is compatible with some 3rd party firmwares like dd-wrt or
tomato. I think those are linux based but i'm not sure. This particular router
would
only be compatible with the micro versions of those firmwares. I don't know how
helpful they would be.
Can wireshark dump network traffic or does that have to be done with the router?
Original comment by MichaelA...@gmail.com
on 8 Mar 2010 at 8:17
I just changed the firmware on my router to dd-wrt because the stock firmware
it came
with wouldn't show me a list of connected devices with their mac's and ip's. I
can
now confirm that the psp is in fact using the exact same mac as my pc. The pc
receives a corrupt video stream within a minute whereas the psp will stay
connected
without any problems.
Original comment by MichaelA...@gmail.com
on 8 Mar 2010 at 9:26
I am unable to install tcpdump or any packages on my router due to hardware
limitations. Sorry. Is there another way to obtain dumps of my network? Perhaps
some
sort of virtual router running on my pc where i could possible connect the psp
to my
pc via an adhoc network?
Original comment by MichaelA...@gmail.com
on 9 Mar 2010 at 7:08
here are the two captures :)
Original comment by MichaelA...@gmail.com
on 21 Mar 2010 at 9:30
Thanks for the captures! They are truncated so I can not examine the TCP
payload,
but from what I can see, the only difference is that Windows 7 is not using TCP
timestamps. The PSP does. Perhaps the PS3 is expecting the TCP options to be
present and if not, poisons the video stream. Check if TCP timestamps are
enabled:
>: netsh interface tcp show global
Enable timestamps:
>: netsh interface tcp set global timestamps=enabled
NOTE: I don't know the exact syntax, I guessed "timestamps=enabled", you can
probably run netsh /? to get the proper name if that doesn't work.
If that goes well, you can verify that TCP timestamps are present by dumping the
traffic of an ORP session and checking the TCP header for the options field.
Should
contain a NOP, NOP, then 12-bytes of timestamp.
If you would like me to compare the two sessions further, you can email me two
*full*
captures (don't truncate). Do not post the captures here as they contain
sensitive
information that you don't want to publicly share.
Original comment by darryl...@gmail.com
on 21 Mar 2010 at 1:32
Just a testing follow-up:
I've done the same as you, spoofed the PSP's MAC as my laptop's WLAN MAC using
idstorage manager and macspoofer. This works GREAT by the way! I've haven't
tried
it before... and it works! So now I don't have to use a tunnel to spoof my PC
as my
PSP. Anyway, I've been connected for about 2 hours now without any video stream
corruption problems using the latest SVN build:
http://code.google.com/p/open-rp/wiki/Downloads?tm=2
So, I can verify that yes you can use your PC's MAC and the PS3 has no clue.
So in
your case the difference between our two configurations is that I'm using Linux
(with
TCP timestamps enabled by default), and you're using Windows 7 (with TCP
timestamps
disabled). It would seem like the PS3 actually looks at the timestamp options
field
of the TCP headers and if it's not present, poisons the video stream.
Original comment by darryl...@gmail.com
on 21 Mar 2010 at 3:04
ok.. i sent the two captures and i did see the timestamp (nop, nop, and 12
bytes of
timestamp) in the orp capture. So what else does linux do by default that
windows 7
doesn't? I'm still getting corrupt video stream.
Original comment by MichaelA...@gmail.com
on 21 Mar 2010 at 4:15
"and i did see the timestamp"
So you see the timestamp now that's you've enabled it using netsh?
I haven't received any email yet... which address did you send it to
(darryl242@gmail.com)?
Original comment by darryl...@gmail.com
on 21 Mar 2010 at 4:27
no i replied to the email i got from open-rp that notified me of the new
comment.. i
just sent it to your email though.
Original comment by MichaelA...@gmail.com
on 21 Mar 2010 at 4:30
Did you get the email? I do have timestamps enabled and I believe that they are
showing up on the capture. I still get the corrupt video stream.
Can you confirm from the captures i sent as to whether or not the timestamps are
enabled? If they are I guess I leave the dirty work to you to figure out what
else
might be going on. Let me know how I can help. Now that i have all the dumping
pretty
much figured out I can probably be of more help.
Original comment by MichaelA...@gmail.com
on 21 Mar 2010 at 5:33
Yes! Got the email with attached captures. Studying them I can't see any
significant differences between ORP and the PSP session. I can verify that you
have
indeed enabled TCP timestamps. Since that made no difference, that theory is
out.
So I decided to try the same version you've been testing, ORP v1.3 325 SVN, on
my
WinXP virtual machine. Normally I would use a tunnel set to spoof the PSP's MAC
address, but this time, I tried using your method - spoofing my PC MAC address
on the
PSP (which works awesome under ORP for Linux).
I was very surprised to see the same results you've been experiencing... video
stream
corruption after about a minute. So... I have much more testing to do but
this is
very interesting. ORP v1.3 325 Linux works, ORP v1.3 325 Win32 fails. From the
packet captures I can not see any differences - but there MUST be something
there
that the PS3 "sees" which is causing it to counter. I'll keep comparing and
see what
I find... Thanks for the captures!
There definitely is something that Windows does differently (networking-wise)
that
the PS3 is looking for.
Original comment by darryl...@gmail.com
on 21 Mar 2010 at 10:01
I've noticed that the length of the orp session, before the video stream is
corrupted, usually depends on what is being done during the session. For
example if i
watch a movie saved on the ps3 the corrupt video stream will occur much sooner.
If i
just leave the ps3 on the xmb for the entire orp session it will last a bit
longer.
I'm not sure if that might be a lead to go off of. Could just be coincidental.
I also notice a difference when I watch orp in full screen mode by pressing f11.
Although I would think this has nothing to do with the problem at hand, i have
noticed full screen mode lengthens the time of the orp session. Also the corrupt
video stream message does not show in full screen mode, it just freezes on the
last
frame of the session.
Original comment by MichaelA...@gmail.com
on 22 Mar 2010 at 12:06
It shouldn't matter what you're doing with ORP. Unless watching a video
generates
more key-frames. Key-frames are the only frames that the PS3 encrypts. If it
detects a non-licensed client (ORP), it will encrypt key-frames and then
randomly
change one (or more?) bytes before sending it. This results in a corrupted
key-frame
when decrypted.
Fullscreen mode does nothing different. Errors are supposed to toggle out of
full-screen mode, returning to windowed mode at 480x272. But I guess that's not
working properly under Windows... though I have noticed that malformed
key-frames can
sometimes crash the libavcodec that ORP uses to decoded audio/video. Maybe
that's
why it just crashes.
Regardless, I'm really puzzled by how the PS3 can detect a difference (or
differences) between an ORP session in Linux versus an ORP session in Windows
(XP/Vista/7). I look forward to solving this... but at this point, I have no
theories.
Original comment by darryl...@gmail.com
on 22 Mar 2010 at 1:45
A key-frame would be one where the data contains something like this?
"GET /sce/premo/session/ ctrl HTTP/1.1 User-Agent:..." and so on.
Original comment by MichaelA...@gmail.com
on 22 Mar 2010 at 2:34
Nevermind... I think that would be orp telling the ps3 it is a psp.. right?
Original comment by MichaelA...@gmail.com
on 22 Mar 2010 at 2:38
On frame 8088 of the orp capture i sent you.. orp sends its user-agent info.
Then two
frames later is when the ps3 closes the connection.
So I compared orp user-agent data string with the user-agent data string from
the psp
capture and they are different. Is that normal?
Original comment by MichaelA...@gmail.com
on 22 Mar 2010 at 2:48
Attachments:
The request you are seeing in the ORP captures (@ frame 8088) is sent to the PS3
*after* the corrupted video stream was detected. The URL as you can see in the
image
linked below is for /sce/premo/session/ctrl and the mode is "session-term".
This is
simply how a remote play session is terminated.
The request you are comparing to is for /sce/premo/session, which is opened at
the
beginning of *both* sessions (ORP and native PSP). Look closer toward the top
of the
ORP capture and you'll see that it does the same thing the PSP does.
Basically, these two requests are different because they are requests for two
different resources.
http://orp.ps3-hacks.com/images/user-agent.png
Original comment by darryl...@gmail.com
on 22 Mar 2010 at 8:08
Ok. Does the psp terminate a session differently from orp?
Is there a way to make orp clone a psp session? (i mean make the exact same
requests
in the same order?) I think it would be a nice debugging feature no?
Original comment by MichaelA...@gmail.com
on 29 Mar 2010 at 8:06
any developments/progress?
Original comment by MichaelA...@gmail.com
on 27 May 2010 at 8:06
Original issue reported on code.google.com by
MichaelA...@gmail.com
on 1 Mar 2010 at 8:42