I have a 1GB pci-express NIC peer-to-peer connected to an ethernet video camera.
When there is ethernet traffic on the other integrated NIC (for example during a 4k streaming video from youtube), which I use for LAN and Internet traffic, the video camera stream from the PCI-e NIC is slowed down.
I need priority on the video camera stream. I was assuming that having a dedicated NIC would be a solution for avoid delays, but it is not so.
The video camera manufatcurer does not adopts GIGE Vision standard, it adopts simple UDP.
The 2 NICs are on different subnet.
I tried to increase process priority for the application that acquires from video camera connected to the PCI-e NIC.
I disabled all protocols except TCP/IP v4 from the PCI-e NIC.
I disabled windows firewall.
On the PCI-e NIC I enabled Jumbo Packet, increased the receive buffer and number of RSS queues, increased the priority (by lowering down the "metric" of the PCI-e NIC and increasing the metric of the integrated NIC).
I also tried adding another pci-express 1GB NIC, adopting it for LAN and internet traffic instead of the integrated one, which I disabled.
I am adopting Windows 10, tried NIC Intel CT desktop adapter and Intel I-210, I verified CPU is not overloaded during video stream and CPU is high end XEON 8 cores.
Any idea for not slowing down the video camera stream on the PCI-e peer-to peer-NIC when there is heavy traffic on the other NIC?
Related
I want to develop an android app which uses push to talk or Voip to communicate between 2 mobile devices using a Wi-Fi connection without using a data or the internet.
Is it possible to develop this?
I am looking for a 'free' Wi-Fi Walkie Talkie but I don't know how to start doing it?
For a very simple, initial version, I'd do the following:
Assign a static IP address on each phone
Record the audio and packetise it into a UDP stream that you'll send to the remote IP address
Repackage again the UDP stream and play the audio.
Microphone ---> Samples ----> UDP (over WiFi) ----> Samples ----> Speaker.
There are plenty of enhancements that you can add over the time:
Device discovery
Signalling separate (SIP or custom messages via TCP or UDP to indicate when to start the audio transmission and negotiate the media channel that will be used).
Support for third party devices (SIP)
Use standard paketization using RTP and encode the audio using G711alaw/G711ulaw...
There are plenty options, but you should start by capturing the audio, and sending it over the network, even make packets of 2 seconds with the incurring delay, but that's a point to start. Then, you should lower the packet length to contain 20ms of audio to avoid delays in the transmission.
Hope this helps.
I have a basestation (beaglebone running linux) at my home which is connected to multiple cameras. I connect my iPhone iOS9 to the basestation via TCP and the basestation will stream the video of each camera to a specific UDP port. All is well.
I want to be able to see the cameras when I am not connected to the local network. When my phone is connected to LTE, I have the iPhone connecting to the public address of my router via TCP and with port forwarding, all data is forwarded to the basestation. I am connecting and talking just like it was on the local network with the TCP client. All is well.
The problem is when the video is streamed via UDP on a specific port, no different than when on the local network, the basestation has no problem sending the packets, but the iPhone is not receiving anything. I am using GCDASYNCUDPSOCKET and my cellular carrier is Verizon.
I am wondering if this issue is due to Verizon blocking UDP packets? Or possibly there needs to be something else done other than just binding the iPhone UDP socket to a specific port and calling the beginreceiving function. I feel if it works on the local network, it should work on the cellular network.
I have also tried to ping the address of my cellphone from my computer which does not work. I am guessing the reason is because the iPhone has blocked this. It should be no different than pinging the address of google or anything else.
Please give me some insight on the possible issues or work arounds. I don't think I need to port forward the UDP since it is only outgoing and my Netgear router does not limit any outbound traffic (from the router to the iPhone). I was doing all this TCP before trying to send the video via UDP. It is much slower waiting to receive acks for 5 cameras streaming live video. And when it doesn't receive a packet it backs up the buffer and causes more issues. Also I had an issue with the TCP packets combining together so then I had to implement some kind of custom ack which made the delay worse, or add an end of message, but then it slows down on parsing and since I don't know exactly what data is coming it made things more difficult.
UDP is the way to go, just cannot receive the packets at this time. My understanding is a lot of games use UDP and they work on LTE network, so I'm not quite sure what the problem is. Is there special UDP ports that only work with Verizon?
I want to observe streams between the original screen mirrored from and the target screen mirrored to to check something like frame loss, thus I'm thinking to sniff packets between sender and receiver.
Is there any plugins for Wireshark which enables me to do that..?
What you have to do is to route the network traffic through some network node that you can sniff on. Like your laptop.
I would connect the laptop to the Internet through ethernet and make a wifi hotspot on it. Then tell chromecast to connect to your hotspot. Now you're in the middle between chromecast and the Internet. Wireshark should be able to capture the traffic without any specific plugins.
Make sure you've enabled routing between ethernet and wifi hotspot.
My understanding is that current WiFi driver uses rate control algorithm to choose a data rate within a small set of predetermined values to send packets over the WiFi medium. Different algorithms exist for this purpose. But how does this process work when WiFi driver decides that the connection is lost and shutdown the connection all together? Which part of the code should I read in open source WiFi driver such as MadWiFi and the likes?
The WiFi driver for your hardware which runs in Linux communicates with the WiFi chip which also runs a pretty complex firmware. The interface between the driver and the firmware is hardware specific. In some hardware the detection of connection loss events is done completely by the firmware and the driver only gets a "disconnected" event while in others the driver is also involved.
Regardless of who does what disconnection usually occurs due to either
Receiving a DEAUTH frame from the AP
Detecting too many missing beacons. Beacons are WiFi frames sent periodically by the AO (for most APs every ~100ms) . If you get too far from the AP or the AP was just powered off you stop seeing the beacons in the air and usually you'll signal disconnection or try to roam to a different AP.
Too many failures on Tx of packets (i.e. not receiving ACK frames for too much traffic)
This usually indicates that you've gone too far from the AP. It could be that you can "hear" the AP but it can't hear you already. In this case it also makes sense to signal a disconnection.
For example you can look in TI wifi driver in the Linux kernel drivers/net/wireless/ti/wlcore/events.c and the function wlcore_event_beacon_loss()
In Cfg80211 architecture, assume we are station mode.
driver call kernel API cfg80211_send_disassoc() if we received a deassoc/deauth frame.this function will notify corresponding application (ex wpa_supplicant) a disconnect event.
on another hand, when we decide to disconnect with AP, applicantion (ex wpa_supplicant) can call linux kernel API cfg80211_disconnected(), it will trigger corresponding driver ioctl function to finish disconnection task.
I want to analyze networks traffic but not by connecting it Just
switch on wifi and sniff the packets (IEEE 802.11 Frames)
in promiscuous mode
I have tried libpcap but it may be internally changing datalinktype as i am giving wifi interface in
descr=pcap_open_live("en1", MAXBYTES2CAPTURE, 1, 512, errbuf);
(as we know mac OS x have en1 as wifi interface )
now when i do this
printf("%s", pcap_datalink_val_to_name( pcap_datalink(descr)));
It gives me result "ethernet"
I have tried to capture packets using wireshark without connecting to my wifi network and it worked!!
I was able to capture Beacon , Acknowledgement and Authentication frames without connecting to my wifi network.
now:
do I have to make a network card driver for that or libpcap can do that ?if yes how?
Is wireshark making some kind of driver for that? if yes please help me to locate that in it's source code.
I have tried Apple's CFNetwork but it too can't capture without connecting to the network.
It will be very helpful if i get some suggestion on some user space code as kernel level coding is a little tuff :(
I am coding on MacOS 10.7 in xCode 4.5.1
Update:
I am already doing this:
descr=pcap_create("e1", errbuf);
pcap_set_rfmon(descr, 0);
pcap_set_promisc(descr, 0);
pcap_activate(descr);
descr=pcap_open_live("en1", 2048, 1, 512, errbuf);
And yes there is a little monitor icon at the wifi and I can sniff the
packets but only when I connect to the network, I want to do the same
when I am not connected to wifi like capturing Beacon and
Acknowledgment Frames means packets through which our network card detects available wifi network
If you're running on Snow Leopard or later (which you are, as you're running Lion), you should use the new pcap_create()/pcap_activate() APIs, and turn on monitor mode by calling pcap_set_rfmon() between the pcap_create() and pcap_activate() calls.
That's what Wireshark 1.6.0 and later do if you check the monitor mode checkbox, and what tcpdump 1.0.0 and later, and TShark and dumpcap in Wireshark 1.6.0 and later, do if you specify the -I command-line flag.
By default, Wi-Fi interfaces on many OSes, including but not limited to OS X, supply Ethernet headers, not 802.11 headers, which is why pcap_datalink_val_to_name(pcap_datalink(descr)) is reporting Ethernet headers. On Linux and OS X, you have to go into monitor mode to get 802.11 headers; on *BSD, you can get 802.11 headers without going into monitor mode.
You do not need your own driver to go into monitor mode on OS X; Wireshark does not supply its own drivers.