•   
  • 1
  • 2
  • 3(current)
  • 4
  • 5
  • 20
  •   
[AirPlay][Warning] Don't update to iOS8 if you want AirPlay
#31
stopping the airplay announcement can be achieved by commenting this code line:

https://github.com/xbmc/xbmc/blob/Gotham...s.cpp#L536

for the airtunes announcement this:

https://github.com/xbmc/xbmc/blob/Gotham...r.cpp#L601
AppleTV4/iPhone/iPod/iPad: HowTo find debug logs and everything else which the devs like so much: click here
HowTo setup NFS for Kodi: NFS (wiki)
HowTo configure avahi (zeroconf): Avahi_Zeroconf (wiki)
READ THE IOS FAQ!: iOS FAQ (wiki)
Reply
#32
Thanks - I've noticed with what I've done above on it's own that while Airplay now works (and still works on iOS 7) it kills Airtunes on both, so I'll do a bit of experimentation over the next few days with custom announcements.

Commenting both lines above out will also disable the 10 second txt record refresh hack as well I assume ?
Kodi 18.3 - Mid 2007 Mac Mini, 4GB, 2TB HD, Windows 7 SP1
Kodi 18.3 - Vero4k, Raspberry Pi 2. OSMC.
Reply
#33
mhh not sure about that. But this all sounds really familiar to me. I think the same happend during developing the ios7 workaround Wink (and is documented and burried deep in that big ios7 airplay thread).
AppleTV4/iPhone/iPod/iPad: HowTo find debug logs and everything else which the devs like so much: click here
HowTo setup NFS for Kodi: NFS (wiki)
HowTo configure avahi (zeroconf): Avahi_Zeroconf (wiki)
READ THE IOS FAQ!: iOS FAQ (wiki)
Reply
#34
(2014-09-22, 10:40)DBMandrake Wrote: My feeling is that Apple don't yet think the Airplay video protocol has sufficiently matured, and therefore don't want the burden of supporting the network/protocol API with 3rd party vendors yet, hence Airplay video has not been licensed to anybody at all yet. As long as the Apple TV is the only device to act as an Airplay receiver Apple controls both the client and server end and are able push the Airplay protocol development forward rapidly (dropping support for older versions of the protocol along the way) until they're happy with it.

Apple policy has always been about total control over the hardware/software landscape and the entire user experience.
Just like you can't plug any USB or Bluetooth devices to your iPhone.

If you want any hardware to work with your iPhone/iPad it must be approved by Apple. And not just the hardware, but your entire business plan.
In fact, Apple doesn't even want you to start working on your hardware until they have approved your business plan, the design, look and user experience of it..
It's all part of the "Made For iPod" program.

AirPlay devices also fall into that category (though it's a separate application to lodge after you've joined the Made For iPod)

(FWIW, I am a member of the Made For iPod, and the docs are all there. It's well documented actually)

But Apple won't even issue test keys unless your device has been approved and will only work with that particular device and with the iAP authentication chip you'll have to include in your design.

(2014-09-23, 16:29)DBMandrake Wrote: IIn this case when the name randomly flips over for a short time although the mirroring switch disappears airplay video continues to work, whereas with the wrong port number specified it would fail to connect when the name flipped over to just ITSUPPORT instead of XBMC (ITSUPPORT).

Setting the name exactly the same as XBMC's announcement doesn't seem to work at all however.

Edit: anyone else running windows who wants to try the above - open a command prompt window to run it in, change the name ITSUPPORT to a name that is similar to but different to the name that XBMC normally appears as on your iOS device, and change deviceid to the MAC address of your PC. I'd be interested to see if this works for anyone else on iOS 8.

When trying it make sure you don't turn on the screen mirroring toggle even though it will be available as screen mirroring is not supported.

The iPhone sees the device instantly as soon as you add the FairPlay bit in the "features" field (bit 2).
However, if you set it, you break Airplay audio, as then, no matter what you advertise in the RAOP service, it will use FairPlay DRM for audio
Reply
#35
(2014-09-24, 01:14)jyavenard Wrote: The iPhone sees the device instantly as soon as you add the FairPlay bit in the "features" field (bit 2).
However, if you set it, you break Airplay audio, as then, no matter what you advertise in the RAOP service, it will use FairPlay DRM for audio

Two questions:
1). Are you the same jyavenard of Tomato fame? If so kudos on your contributions to an awesome project.
2). Are you allowed to post the document online, or even the feature bit meanings? In the iOS7 issue thread we spent weeks going through different feature bitmasks, but at a certain point we found that the docs on the Net are sorely outdated. Even if you could PM Memphiz it would be great...
3). I read your post to mean that setting FairPlay causes iphone to pickup the source quicker than if it isn't set... Did I misread that? If not, is it known why?
Reply
#36
(2014-09-24, 01:48)edrikk Wrote: Two questions:
1). Are you the same jyavenard of Tomato fame? If so kudos on your contributions to an awesome project.
yes.
thank you.

Quote:2). Are you allowed to post the document online, or even the feature bit meanings? In the iOS7 issue thread we spent weeks going through different feature bitmasks, but at a certain point we found that the docs on the Net are sorely outdated. Even if you could PM Memphiz it would be great...
no.. It's under NDA, and I made sure I used no information contained in the made for ipod program made its way in my work related to MythTV (I am the maintainer of the AirPlay code there

Having said that, some people have figured out most of it right: in particular this one:
http://nto.github.io/AirPlay.html

Quote:3). I read your post to mean that setting FairPlay causes iphone to pickup the source quicker than if it isn't set... Did I misread that? If not, is it known why?

that's 3 questions Smile

no you didn't misread. Reporting FairPlay support fixed all the visibility issues, no need to refresh the bonjour advertisement etc..

If you check, you'll find that programs that do support FairPlay (AirServer and Reflector), didn't experience any issues like XBMC or MythTV did. They are also the program that support screen mirroring (which requires FairPlay)

Last year when iOS 7 broke AirPlay I was convinced that Apple had then enforced FairPlay and there were nothing we could do. You basically had to choose between AirTunes or AirPlay and we wouldn't be able to have both working at the same time.

Luckily Memphis proved me wrong... Hopefully, I'll be proven wrong again.
Reply
#37
@jyavenard thx for joining the party Smile

I have updated my testdevice to ios8 and played a bit with the findings of DBMandrake. The linked testbuilds add an option "iOS8 compatibility mode". (only visible in expert settings level!).

This basically only changes the airplay announcement to increase the protocol number and changes the announced name from Xbmc,1 to AppleTV2,1. Those 2 changes are enough to make the detection as video target 100%.

It also implicitly forces fairplay on airtunes (so its not only the feature bits @jyavenard it seems the protocol version can override or "add" feature bits aswell). Also this change implicitly sets the featurebit for photo asset cache (meaning that the client will send asset cache messages). Thats why i had to add my asset cache implementation (i did it during ios7 already).

Of course if you switch on ios8 compatibility you loose airtunes streaming (because of the enforced fairplay encryption).

The code for the testversion is here:

https://github.com/Memphiz/xbmc/commits/ios8airplay

osx:
http://mirrors.xbmc.org/test-builds/osx/...x86_64.dmg

ios:
http://mirrors.xbmc.org/test-builds/darw...ay-ios.deb

atv2:
http://mirrors.xbmc.org/test-builds/darw...y-atv2.deb

win32:
http://mirrors.xbmc.org/test-builds/win3...irplay.exe

android-arm:
http://mirrors.xbmc.org/test-builds/andr...bi-v7a.apk

I think in the end wie might end up to have this ios8 compatibility option which then might need to announce a complete seperated airtunes announcement (meaning you see "XBMC/Kodi" as target for video and audio and "XBMC/Kodi-Audio" as audio only target). Unfortunately i was not able to seperate those announcements yet as the client merges those based on something (to be figured out .- either mac addresss or ip or announced mac or what not).

@jyavenard do you have any more info about the commercial software like AirServer? Do you know if they do it the official way somehow? (signing contracts with apple)? Seems the only real goal would be to reverse engineer the keys out of their binaries somehow (i am not the on who is capable of doing this though).
AppleTV4/iPhone/iPod/iPad: HowTo find debug logs and everything else which the devs like so much: click here
HowTo setup NFS for Kodi: NFS (wiki)
HowTo configure avahi (zeroconf): Avahi_Zeroconf (wiki)
READ THE IOS FAQ!: iOS FAQ (wiki)
Reply
#38
(2014-09-24, 10:46)Memphiz Wrote: I think in the end wie might end up to have this ios8 compatibility option which then might need to announce a complete seperated airtunes announcement (meaning you see "XBMC/Kodi" as target for video and audio and "XBMC/Kodi-Audio" as audio only target). Unfortunately i was not able to seperate those announcements yet as the client merges those based on something (to be figured out .- either mac addresss or ip or announced mac or what not).
I had exactly the same idea and was already experimenting with this idea when I saw your post - my suspicion is that the MAC address might be used to uniquely distinguish devices, and that lying about the MAC address for the raop service in both bonjour announcements and within the requests themselves (if relevant) may be all that's needed other than changing the name to make the client see it as two independent devices, one video one audio.

I can't see why we can't lie about the MAC address for one of the services because the protocols are all capable of running over a routed network when a bonjour proxy is used, in which case the client has no way to verify the validity of the claimed MAC address against the MAC address in the packets as it may be the MAC address of a router.
Kodi 18.3 - Mid 2007 Mac Mini, 4GB, 2TB HD, Windows 7 SP1
Kodi 18.3 - Vero4k, Raspberry Pi 2. OSMC.
Reply
#39
I don't think there is an easy way to fake the mac address which comes from the layer2 of the network stack. We only can influence the mac adress used in the announcements i guess.
AppleTV4/iPhone/iPod/iPad: HowTo find debug logs and everything else which the devs like so much: click here
HowTo setup NFS for Kodi: NFS (wiki)
HowTo configure avahi (zeroconf): Avahi_Zeroconf (wiki)
READ THE IOS FAQ!: iOS FAQ (wiki)
Reply
#40
(2014-09-24, 13:20)Memphiz Wrote: I don't think there is an easy way to fake the mac address which comes from the layer2 of the network stack. We only can influence the mac adress used in the announcements i guess.
No I don't mean faking the mac address in the actual layer 2 Ethernet packet headers - we can't easily do that. I mean faking the address in the bonjour announcements and within the protocol messages themselves.

I see from that document that the Airplay Video protocol does send the mac address embedded in the http request headers as well - which would have to match those sent in the bonjour announcements. However the Airplay Audio protocol doesn't (from a quick skim over that document) appear to embed the mac address within the protocol - hence I thought it would be easier for me to try faking the mac address for the raop service rather than the airplay service as then I don't have to edit the code in XBMC, other than disabling the built in announcements.

I'm trying to set up a test but I keep getting interrupted at work by actual work... Big Grin
Kodi 18.3 - Mid 2007 Mac Mini, 4GB, 2TB HD, Windows 7 SP1
Kodi 18.3 - Vero4k, Raspberry Pi 2. OSMC.
Reply
#41
hahahahaa - yeah thats something we all have to deal with right? Wink
AppleTV4/iPhone/iPod/iPad: HowTo find debug logs and everything else which the devs like so much: click here
HowTo setup NFS for Kodi: NFS (wiki)
HowTo configure avahi (zeroconf): Avahi_Zeroconf (wiki)
READ THE IOS FAQ!: iOS FAQ (wiki)
Reply
#42
Ok Memphiz, I think I might have something here:

Code:
dns-sd -R 74:D4:35:57:00:[email protected] _raop._tcp local 36666 txtvers=1 cn=0,1 ch=2 ek=1 et=0,1 sv=false tp=UDP sm=false ss=16 sr=44100 pw=false vn=3 da=true vs=150.33 md=0,1,2 am=Xbmc1,1
dns-sd -R ITSUPPORT _airplay._tcp local 36667 deviceid=74:D4:35:57:00:E5 features=0x100029FF model=Xbmc1,2 srcvers=150.33 xbmcdummy=evendummy

This is in conjunction with an XBMC 13.2 build with built in Bonjour annoucements disabled in the source as you described earlier.

For me at least my iPad is immediately and always detected as a video device and both video (tested with Instacast) and Audio (tested with Spotify) appear to work. Big Grin The mac address is the valid one.

I haven't done extensive testing nor have I tried it on an iOS7 device yet as I don't have one handy. But it's a start. It even seems to hand off gracefully when switching between video/audio apps. The only issue I see is the mirroring switch still appears. (And must be left turned off)

How did I come up with the strange combinations of parameters above ? Lets just say it was a bit of manual fuzzing of the individual parameters Wink
Kodi 18.3 - Mid 2007 Mac Mini, 4GB, 2TB HD, Windows 7 SP1
Kodi 18.3 - Vero4k, Raspberry Pi 2. OSMC.
Reply
#43
Some more observations while the myriad of combinations I tried are still somewhat in my head.

1) Specifying AppleTV3,1 or AppleTV2,1 for am/model causes some of the feature bits to be overridden, for example turning off bit 7 for screen mirroring (changing from 0x100029FF to 0x1000297F) does nothing, however if the model is something else like Xbmc1,1 the feature bits (or at least that particular one) do have an effect. I guess apple assume if the model number is one of their AppleTV's they can make assumptions about feature set from the version number alone and ignore (some of ?) the feature bits.

2) If a specific AppleTV model is specified then Fairplay encrypted audio is forced on when the Airplay video announcement is seen, but if its an unknown model such as Xbmc,1 this doesn't happen if the feature bits and version numbers are correct. Smile (Seems to be another "assumption" by Apple based on model number, like the screen mirroring feature bit above)

3) It looks like we need to leave mirroring support enabled in feature bits even though we don't support mirroring. If I turn off bit 7 AND the model is not AppleTVx,x (so that turning of the bit actually has an effect) video no longer works - it connects to the device but video playback stalls in limbo. So users will just need to know to leave mirroring turned off.

4) Reliable detection as a video device seems to be dependent on both the vs/srvvers being higher than a certain number and mirroring support (bit 7) being advertised, and possibly other feature bits as well. I just started with Reflector's feature bit value and that worked fine with my other changes so I didn't stray too far from that apart from trying to disable the mirroring support option.

5) The model/am fields don't seem to matter except that they shouldn't be an actual recognised AppleTV model number that Apple special cases like AppleTV3,1. I changed them both back to the original Xbmc,1 and it still works fine. (At first I thought having the two model names slightly different was part of the secret of success but it's not)

The following works just as well:

Code:
dns-sd -R 74:D4:35:57:00:[email protected] _raop._tcp local 36666 txtvers=1 cn=0,1 ch=2 ek=1 et=0,1 sv=false tp=UDP sm=false ss=16 sr=44100 pw=false vn=3 da=true vs=150.33 md=0,1,2 am=Xbmc,1
dns-sd -R ITSUPPORT _airplay._tcp local 36667 deviceid=74:D4:35:57:00:E5 features=0x100029FF model=Xbmc,1 srcvers=150.33 xbmcdummy=evendummy

So in essence all that needs changing from the original XBMC implementation is the "features" bitmask and the vs/srcvers version numbers. Smile (And the 10 second record refresh hack is also no longer needed and may cause problems so should be removed)

I've also tested it with a 3GS running iOS 6.1.3 and it works fine there too. iOS 7 still unknown but I'll try to get a chance to test it tomorrow.
Kodi 18.3 - Mid 2007 Mac Mini, 4GB, 2TB HD, Windows 7 SP1
Kodi 18.3 - Vero4k, Raspberry Pi 2. OSMC.
Reply
#44
Nice dude - i will give this a shot once i am home. If this is true you finally might have solved android with ios7 clients aswell. The problem is - i don't have any ios7 device anymore now that i have bumped it to ios8 Wink. But i know someone who can test it.

Thx for this work - looks like you did a great job in fuzzing with apple Big Grin
AppleTV4/iPhone/iPod/iPad: HowTo find debug logs and everything else which the devs like so much: click here
HowTo setup NFS for Kodi: NFS (wiki)
HowTo configure avahi (zeroconf): Avahi_Zeroconf (wiki)
READ THE IOS FAQ!: iOS FAQ (wiki)
Reply
#45
I still have three iOS 7 devices at home that I can test with, which won't be getting updated until at least 8.0.1 - my iPad was my iOS 8 guinea pig and I've had enough problems (crashes/reboots/sluggishness) that the rest won't get updated until those issues are fixed by Apple!

I have noticed one small problem with my proposed fix above - still photo playback from the photo library is a little bit flaky. It's actually showing the next image not the current one! I think that might be related to what you were saying earlier about photo caching though - I assume your photo cache code is not in 13.2 ? Perhaps I can try disabling bit 13 for photo caching ?? (I haven't checked, but Reflectors bitmask probably has it enabled)

Edit: I can save you the trouble of answering this one - I just tried changing the features bitmask to disable bit 13 and it is now detected only as an audio device. So photo caching support has to be advertised for any video to work. Sad

Other than that I really can't fault it.
Kodi 18.3 - Mid 2007 Mac Mini, 4GB, 2TB HD, Windows 7 SP1
Kodi 18.3 - Vero4k, Raspberry Pi 2. OSMC.
Reply
  •   
  • 1
  • 2
  • 3(current)
  • 4
  • 5
  • 20
  •   
 
Thread Rating:
  • 1 Vote(s) - 4 Average



Logout Mark Read Team Forum Stats Members Help
[AirPlay][Warning] Don't update to iOS8 if you want AirPlay41
This forum uses Lukasz Tkacz MyBB addons.