I have implemented basic WEBRTC peer connection between two clients and uses RTCPeerConnection and getUserMedia APIs for it. I am fetching Audio tracks only from the stream.
Even though my signalling works, ice agents are shared, streams are shared as well.
The audio comes out distorted completely.
However, if I utilize a VPN on one device the other device can hear the audio coming from the device with VPN very clearly with no hiccups.
NOTE:
I tried this with only stun and with a combination of stun and turn servers(viagenie).
Can someone tell me how do i debug the issue, what to look for?
Is my ISP involved in messing around with the media stream? (I live in the UAE.)
Thanks in advance!
i think the problem is UAE ISP block the STUN/TURN PORT (3478,5766 ...)
you can try to use 443/80 port?
Related
In a cellular environment, the ip address assigned for a phone changes dynamically.
So i wonder how WebRTC deals with this issue.
Does WebRTC has some feature called 'Path Migration' like QUIC ?
Is ICE Restart what i am finding?
There is an RFC8016 TURN about mobility to reuse TURN session in case of IP change, but it is AFAIK not implemented in the actual WebRTC stack.
AFAIK WebRTC does not handle yet this case.
You could detect the error on client side and restart ICE agent.
I have a small home network that I would like to analyze and capture the traffic on. What are my options for doing this? Ultimately, I would like to use a packet capture library, such as libpcap, to sniff the network in real-time as my router receives packets. I'm mainly interested in HTTP traffic. Thus far, when I run my program, I only seem to be able to see packets sourced or destined to my machine. Is there a way that I may inspect any traffic that travels through my wireless modem/router?
From the research I've done, it seems that the only way this is possible is through ARP poisoning or using a CISCO router that features Embedded Packet Capture.
Has anyone tried either of these and how successful were you? Are these my only options or is there something I may have overlooked?
Hi :) I think ARP poisoning and so on is not so easy to drop in.. ;) but you could start by trying one of the most famous network packets analyzer: Wireshark. Networking is very far to be easy.. :P but Wireshark will help you a lot and, btw, supports also libcap. Hope that helps :)
I have 2 network devices that talk to each other over Ethernet. I would like to sniff the traffic using Wireshark. But the devices are going through a switch. The switch routes the traffic to only the ports that need the data.
At another location I have a hub. All the traffic is repeated across all the ports.
Is there a way to tell the switch to send the traffic down my port also?
EDIT: This is an unmanaged switch.
You might want to look into ARP spoofing.
http://en.wikipedia.org/wiki/ARP_poisoning
Since this is an unmanaged switch, the only way that I can think of is to temporarily put a hub between the switch and one of the devices you want to monitor, then plug a laptop into that hub to do the monitoring. The laptop should now see all traffic between the device and the switch.
This is pretty easy since you can do it at the location of one of the devices. You just need a hub, two more lengths of CAT cable and the computer you are using to monitor with.
The switch may have a management interface that lets you do that. Be warned that if you do, you'll wreck performance on the switch since everything attached to it will now have to deal with collisions.
If the switch is a managed switch, it likely has a mode to act like a hub. Just be careful not to leave it like that.
Some will also have ways to mirror ports and such as well. You need to find out what kind of switch it is.
RE Edit: If it is unmanaged, then you are boned. Use a hub, a managed switch or run wireshark on the computer(s) affected.
You could try a port redirector, like this one. You would configure one device to talk to your computer instead of the other device, and the redirector will send the data to the real target. There are several programs like this out there, or you could write your own.
I'm trying to confirm a user a unplugged my embedded device from a network before performing some maintenance. I'm considering "ping"ing all IP address on my sub-net, but that sounds crude. Is there a broadcast/ARP method that might work better?
You can try a broadcast ping (this is from linux):
ping -b 255.255.255.255
Another option is to download Nmap and do a ping-scan.
You could use nmap. It's still crude, but at least it's using a tool designed to do it so you don't have to spend time on it.
If you can't get reliable link state information from your Ethernet device (which most chipsets should support these days, BTW...), sending an ARP request for each IP on your local subnet is a decent substitute. The overhead is minimal, and as soon as you get a single response, you can be sure you're still connected to a network.
The only possible problem I see here, is that if your device is on a /8 subnet, it can take quite a while to loop through all 4294967296 possible IPs. So, you may want to consider some optimization, such as only sending ARP requests for your default gateway, as well as all IPs currently in your ARP table.
If there's a peer you know you were connected to recently you could try pinging or arping that first. That could cut down on the traffic you're generating.
you could also run tcpdump -n to see what's active on the network too.
Not receiving any responses to ICMP pings or ARP requests is not a 100% guarantee that there's no network connection. For instances, there might be devices on the network that are firewalled off.
EDIT: May be you could access some lower-level information on your embedded device to check whether the network interface has its link up without actually sending any data.
Is there any chance that your device supports UPnP or Bonjour? Beside of the low-level protocols your should also have a look at these protocols which support some kind of plug-&-Play functionality. A UPnP device for example sends a message on the LAN before it is switched off (though, this doesn't help if it is just removed by unplugging it...).
How can I connect a system to a network and sniff for virus/spyware related traffic? I'd like to plug in a network cable, fire up an appropriate tool sand have it scan the data for any signs of problems. I don't expect this to find everything, and this is not to prevent initial infection but to help determine if there is anything trying to actively infect other system/causing network problems.
Running a regular network sniffer and manually looking through the results is no good unless the traffic is really obvious,but I havn't been able to find any tool to scan a network data stream automatically.
I highly recommend running Snort on a machine somewhere near the core of your network, and span (mirror) one (or more) ports from somewhere along your core network path to the machine in question.
Snort has the ability to scan network traffic it sees, and automatically notify you via various methods if it sees something suspicious. This could even be taken further, if desired, to automatically disconnect devices, et cetera, if it finds something.
Use snort: An open source network intrusion prevention and detection system.
Wireshark, formerly ethereal is a great tool, but will not notify you or scan for viruses. Wireshark is a free packet sniffer and protocol analyzer.
Use the netstat -b command to see which processes have which ports open.
Use CPorts to see a list of ports and the associated programs, and have the ability to close those ports.
Download a free anti-virus program such as free AVG.
Setup your firewall more tightly.
Setup a gateway computer to let all network traffic go through. Take the above recommendataions to the gateway computer instead. You will be checking your whole network instead of just your one computer.
You can make Snort scan traffic for viruses. I think this will be the best solution for you.
For watching local network traffic your best bet (with a decent switch) is to set your switch to route all packets out a specific interface (as well as whatever interface it would normally send). This lets you monitor the entire network by dumping traffic down a specific port.
On a 100 megabit network, however, you'll want a gigabit port on your switch to plug it into, or to filter on protocol (e.g. trim out HTTP, FTP, printing, traffic from the fileserver, etc.), or your switch's buffers are going to fill up pretty much instantly and it'll start dropping whatever packets it needs to (and your network performance will die).
The problem with that approach is that most networks today are on switches, not hubs. So, if you plug a machine with a packet sniffer into the switch, it will only be able to see traffic to and from the sniffing machine; and network broadcasts.
As a followup to Ferruccio's comment you will need to find some method of getting around your switches.
A number of network switches have the option of setting up port mirrors, so that all traffic (regardless of the destination) will be copied, or "mirrored", to a nominated port. If you could configure your switch to do this then you would be able to attach your network sniffer here.
Network Magic, if you don't mind something that's not open source.
You can use an IDS, hardware or software
http://en.wikipedia.org/wiki/Intrusion-detection_system