I'm working with a WebRTC stack that consists of a (firewall-enabled) embedded Linux device, an iOS mobile app, and self-maintained signaling, STUN, and TURN servers.
In 99% of network configurations, the setup works just fine. However, when the embedded Linux device is connected to a Verizon Jetpack (4G LTE), the device cannot establish a WebRTC connection with the mobile app (regardless of whether the mobile phone is connected to the Jetpack or some other network).
In an effort to debug, I took down the entire firewall on both IPv4 and IPv6, but it made no difference.
Then, I kind of randomly discovered that if I add a masquerading post-routing IPv4 rule to the device's NAT table, it starts working! Specifically, this is the iptables command that I used:
$ sudo iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE
Why would this rule get the WebRTC connection working? And is there a more proper way to achieve the same result? The rule above seems too liberal.
I found this question because I was also experiencing a WebRTC ICE timeout when trying to connect to a device on the Jetpack's network. I don't know anything about iptables or firewall/DNS/NAT configurations, but your discovery gave me a clue that it must be some settings in the MiFi itself.
Looking at http://my.jetpack (the Jetpacks web config page/app/thing) I discovered a setting that was labelled something like "Enable passthrough VPN" and it was defaulted to true/on. Toggling that to false/off appears to have fixed the connection issue for me.
I'm not 100% sure this is the "real" issue since it seems like two devices on the same VPN should be able to connect. Hopefully it gives you a little bit of a clue in your own search.
Related
is there a way to connect a dvr tuner to a Plex Server hosted in Hyper-V?
I have searched but could not find a Question about this topic.
My build is a Win22 Datacenter Server running Plex in Hyper-V. A Hauppauge dualHD is connected to the Win22 Datacenter Server via USB.
Thanks for your help!
Current Answer
I'm updating my answer as I didn't realize it was a tuner and not a DVR box connected to your TV.
From what I'm seeing online, your best bets are:
use Enhanced Session Mode to connect the device over RDP (which only supports some devices)
use a third-party tool such as Donglify (this is from results on Google. Buy at your own digression) to allow USB passthrough
use a Type 2 hypervisor (VirtualBox, VMware) to run your instance of Plex instead
run Plex outside of Hyper-V on the same system with a sandboxed user
run Plex on another device entirely, such as a Raspberry Pi.
I can't help with the first, as it requires some gpedit.msc magic I cannot do, or second as I have never used one.
3rd option will reduce program speeds which may cause slowdown if multiple people stream at once.
4th option is my personal recommendation, as you bypass the need to use a hypervisor entirely and keep on the same device.
5th is only good if you use a USB-based drive and have a decent bit of experience with Linux.
Old Answer
Kept for the sake of archival.
You'll want to use Powershell and the Add-NetNatStaticMapping cmdlet to allow inbound connections to the Hyper-V server. This will need a vNAT adapter set up. See the linked blog post (not mine) if you need help with that, too.
Assuming the vEthernet connection has an internal IP of 192.168.10.2 and a NAT network name of NATSwitch, with Plex on the default port of 32400:
Add-NetNatStaticMapping -ExternalIPAddress "0.0.0.0/24" -ExternalPort 32400 -Protocol TCP -InternalIPAddress "192.168.10.2" -InternalPort 32400 -NatName NATNetwork
You will most likely need to replace the internal IP, port, and NAT name.
After this is set up, you'll need to point your DVR to the IP of the Windows Server box.
Sites referenced:
Plex support page on ports to forward
A GitHub user's blog, specifically a post on port forwarding
What is the proper way to connect an app to a device? At the moment, I have a raspberry pi 3 that controls something about electricity and an iPhone app I created. Every time the app goes to foreground, it sends a UDP broadcast message, when the app receives a response from the raspberry pi, it uses that IP address (in the IP header) to consume the web services I created in the hub. This UDP process is done all the time you run the app. Is this what IOT devices usually do? I assume the raspberry pi IP will change sooner or later.
A colleague of mine told me another way: After the first time I get the IP address, instead of using UDP broadcast messages every time the app runs, use ICMP to ping the previously saved IP address to see if it is responding. In that case, I use the web services with that IP address, otherwise, use the UPD broadcast message again.
I don't see the point of that. Basically because the system is not faster using ICMP. (a UDP request is more or less as fast as an ICMP request). Moreover, maybe, another device started using that IP address now (like a smart TV or a smart plug) and for that reason, it is not going to reply to the network requests sent by the app. In that case, the app cannot recover, because it thinks it is already connected to the proper device. As far as I understand, ICMP is a protocol use for diagnosis, not for devices discovery.
What do you think? What's the process used by devices like Alexa, Philips Hue, Smart plugs... to solve the problem of discovering the devices by their apps?
It seems Philips HUE is using SSDP, which under the hood uses a UDP broadcast message. Is it used every time you run the app to discover the IP address? (I am going to check this later with wireshark)
Thanks for suggestions.
You can enable the hostname of your Raspberry Pi to be accessible on your local network through:
http://raspberrypi.local
To enable it, you need to install Bonjour support on your Raspberry Pi by installing the Avahi mDNS daemon (implements Apple's Zeroconf architecture):
$ sudo apt-get install avahi-daemon
Update boot startup:
$ sudo insserv avahi-daemon
Restart to apply the new configuration:
$ sudo /etc/init.d/avahi-daemon restart
I'm not quit sure if I'm on the right site for this, but I'll give it a try. I have a couple of usb devices plugged in my Raspberry Pi model B. But when I plug in a WiFi dongle, it just shuts down all the other usb devices, and the dongle itself doesn't even work. Has anyone any idea what moght solve my problem? Thanks a lot!
I guess the problem is the amount of current that your Raspberry Pi is able to source. If you are not using a Hub it makes sense that when you connect your WiFi dongle the USB ports are disable to avoid getting to much current from your Raspberry Pi.
WiFi dongle consumes lot of USB power. You need external powered USB hub, or you can maximize the input current for your pi
Based on its documentation, Pi 2 can be powered up to 2A current
I had this problem too. It was easy to fix for me, but this may not help. This turned out to be a settings / driver error for me. If this does not work, you should try a different power source with a 2A current.
I have an answer for this. If you can run the command 'lsusb' okay, and it shows your wifi dongle is attached, you will need to edit your /etc/network/interfaces file.
First, find your ip and gateway settings
ifconfig
That should display your ip address. Write down the default gateway and this IP address.
Now, enter this into the command line:
Sudo nano /etc/network/interfaces
So, that has opened the interfaces file. Completely rewrite the file to the following (YOU SHOULD TAKE A PICTURE OF THE CURRENT FILE IN CASE THIS GOES WRONG):
auto lo
iface lo inet loopback
#auto eth0
#allow-hotplug eth0
#iface eth0 inet dhcp
allow hotplug wlan0
iface wlan0 inet static
address you_got_this_in_step_1
network 192.168.0.225 #Change this to your setting.
gateway default_gateway_from_step_1
dns-nameservers 8.8.8.8
wpa-ssid YOUR_NETWORK_SSID
wpa-psk YOUT_NETWORK_PASSKEY
allow-hotpug wlan1
iface wlan1 inet manual
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
ctrl+x and save the file, yes on overwrite
sudo service networking restart
The pi should do some things and restart okay. If not, please set the file back to the original (should have screenshotted the file).
I also recommend that you do this locally and not through SSH.
Thanks for reading my answer and I hope it helps.
We have a wildly 8.2 running on a virtualized ubuntu 14.04 behind a firewall (against DoS attacks,...) in a DMZ. (About 1200 - 3000 requests per hour.)
With Safari the download of some resource files often (about every 2nd time) fails (s. screenshot, all files are locally stored) while there is rarely a problem with other browsers (chrome, firefox)
Is there any plausible cause why there is a different behavior with Safari than with other browsers?
Has anybody ever had similar problems maybe regarding some firewall setting?
Is there any other hint where we could start looking for the cause of the problem? (Implementation, router, lack of resources...)
I know, the question is a little unprecise, that's probably why it was voted down. But I'll post what the solution was anyway.
On the server side we ran a
tcpdump -i eth0 -n -A dst port 80 | grep 'specificUrlPath'
on some other (client) machine we issued a
curl -X POST http://hostname/specificUrlPath
So we saw that the request did not always reach the server network interface and knew that there had to be a problem with the network in between.
The cause for the problem was, that NAT was switched on on the router for the server machine and the NAT implementation was obviously not able to manage as many connections. As soon as NAT was switched off everything worked as it should.
I am not sure, why requests of some browsers were more likely to be served than by others but I guess this is also due to the specific router software.
I'm using NSURLConnection to access a web service (on a .local host). When I access the host by hostname, I'm seeing a delay of 5+ seconds, but when I access it by IP, the connection completes almost instantly.
Running the app on an actual iPhone, instead of the simulator, does not show any delays at all (testing was done on the same network connection). So this seems to be a problem specific to the iOS Simulator or OS X.
I'm able to simulate the problem using the following terminal commands:
nslookup webservice.myhost.local (which is fast)
dscacheutil -q host -a name webservice.myhost.local (shows the delay)
When analyzing the network traffic using Wireshark of the dscacheutil command, I'm seeing several Standard query AAAA requests which are marked red and get an empty response. Once these are done, I see a Standard query A request which has a response containing the correct IP address. The AAAA requests take up about 5 seconds, which would explain the delay.
Does the web service perhaps have IPv6 enabled and you can't use that from the simulator?
I see this on OSX for example when running a local IPv4 only DNS service - if I run dig #localhost is hangs for some seconds until the initial IPv6 connection times out, and then it tries IPv4.
This answer solved the problem for me. (Create an IPv6 ::1 loopback entry to go along with each 127.0.0.1.)
For anyone else who stumbles across this issue... I myself had to disable IPv6 on my machine to avoid the hang in the simulator while IPv6 fails. I did so following these instructions: https://discussions.apple.com/message/18097613#18097613
Which were to:
"To disable IPv6 in OS X Lion, you will need to use the Terminal.
Applications > Utilities > Terminal
To determine what are all of your Mac's network interfaces are, issue the following command: networksetup -listallnetworkservices
To disable IPv6 for wireless, issue the following command: networksetup -setv6off Wi-Fi;
To disable IPv6 for Ethernet, issue the following command: networksetup -setv6off Ethernet
To re-enable IPv6, use -setv6automatic instead"