iOS UPnP/SSDP Multicast over USB Tethering

Hello,


I'm working with a solution for enterprise servers, which would send a a multicast discovery (SSDP) over a USB tethering network to ensure that the user is talking to our hardware, but after tons of trials, wireshark sniffing and etc. I downloaded the nmap to check the udp port (1900) and list as closed.




So my question is:


1.) Is the SSDP blocked on hotspot mode for some real security issues?

2.) Is there any way to graceful unlock this Port

3.) Why disabling this specific port multicast and let unicast go free on this network?

Tested target: iPhone 6 - iOS 10.1.1


Note: I'm GCDAsyncUdpSocket


Regards

Accepted Reply

My guess is that Apple made a decision to block on the iOS firewall for some reason (security?), because I noticied that bonjour/zeroconf is not blocked on the tethering (which does not help me at the moment).

If Bonjour is working then it’s unlikely that your app is explicitly blocked, but rather that it’s hard to get multicast right in the general case. The specific issue is that you have to identify the interface you want to multicast on, and there’s no supported way to identify the tethering interface. You can get an interface list (via

getifaddrs
) but you can’t tell them apart in any future proof way.

Honestly, I’m inclined to label this whole approach as unsupported. As I mentioned before, tethering is intended to be a user-level feature for accessing the WWAN, not a developer-level feature for doing TCP/IP over USB communication to apps running on the iOS device. While you might be able to get this working on current versions of iOS, my concern is that it’ll break irrecoverably on future systems.

Imagine that a future version of iOS explicitly blocked apps from talking to the tethering interface. What would break? Well, none of Apple’s stuff would break, because any communications we need to do over the interface is done by system services, not apps. And the user-level tethering feature wouldn’t break, because users tether in order to access the Internet, not the iOS device. OTOH, your app would break, and that’s not a good place to be.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Replies

I'm working with a solution for enterprise servers, which would send a a multicast discovery (SSDP) over a USB tethering network to ensure that the user is talking to our hardware …

USB tethering was designed for… well… tethering (that is, tethered device to wider Internet communication) not for this scenario (tethered device to iOS device communication, or vice versa), so I’m not surprise you’re having problems here (especially given that IP multicast requires interface specific smarts; see the discussion of

IP_MULTICAST_IF
in
ip
).

Can you explain more about your requirements here? It seems like you might be better off running this over a point-to-point Ethernet link.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

I know it sounds too much complex for a simple thing, which is communicate with a Embedded Linux over a USB cable.


We've a "management appliance" for server products that shares the host USB. For now it's only supporting tethering (RNDIS / IPHETH - Serial/Usb data only in the end of next year ).


Our target is to provide a way to the user control / configure this management appliance via the USB tethering. (LAN / WiFi is not a option). And the requirement of the SSDP is to perform a handshake with this protocol, otherwise the management appliance will refuse the network communication. Do you see anything we can do?


My guess is that Apple made a decision to block on the iOS firewall for some reason (security?), because I noticied that bonjour/zeroconf is not blocked on the tethering (which does not help me at the moment).



Thanks!

My guess is that Apple made a decision to block on the iOS firewall for some reason (security?), because I noticied that bonjour/zeroconf is not blocked on the tethering (which does not help me at the moment).

If Bonjour is working then it’s unlikely that your app is explicitly blocked, but rather that it’s hard to get multicast right in the general case. The specific issue is that you have to identify the interface you want to multicast on, and there’s no supported way to identify the tethering interface. You can get an interface list (via

getifaddrs
) but you can’t tell them apart in any future proof way.

Honestly, I’m inclined to label this whole approach as unsupported. As I mentioned before, tethering is intended to be a user-level feature for accessing the WWAN, not a developer-level feature for doing TCP/IP over USB communication to apps running on the iOS device. While you might be able to get this working on current versions of iOS, my concern is that it’ll break irrecoverably on future systems.

Imagine that a future version of iOS explicitly blocked apps from talking to the tethering interface. What would break? Well, none of Apple’s stuff would break, because any communications we need to do over the interface is done by system services, not apps. And the user-level tethering feature wouldn’t break, because users tether in order to access the Internet, not the iOS device. OTOH, your app would break, and that’s not a good place to be.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Gotcha,


Yes, it's true that it's not that easy to get the tethering interface and do multicasts, also it's quite a "delicated" situation, as you pointed out, it'll easily break.



And regarding the ifaddrs, I've a underlaying objective-C code to do this job and interface it to swift 3:



-> I get all network interfaces, build a network object (contaning name, class, addr, ipv4, ipv6 etc) and filter by: name contains name bridge, family ipv4, is up, not loopback and supports broadcast.


The multicast DOES works on iOS simulator (got the protocol fully working, BUT on iOS simulator there's no BRIDGE interface, I use the en0 so its a completely different history), but doesn't work on the device, meaning the old history: What works on the papper not necessarily works on the real case.


Thanks eskimo!