I have a closed third party system that sends a unicast UDP stream (MPEG-TS) that I'd like to access in two different programs on the same computer. I can not change anything on the source, not even IP or Port.
Is there any other option than to write my own little program that captures the stream and then creates to new streams and resends both?
It seems that only one of the two destination programs handles multicast, so I need two unicast streams.
You should be able to use socat to forward unicast UDP to a multicast group, or just save data into a file and process later.
Edit 0:
Here is an example (this is on Linux - don't have any Windows boxes). Listen on unicast port 4242, forward to multicast 224.10.10.10:5252 (you might have to add ip-multicast-loop option if you are doing everything on the same machine):
~$ socat UDP-LISTEN:4242 UDP-DATAGRAM:224.10.10.10:5252
Receive on multicast (needs interface address or name), forwards to unicast 192.168.0.1:6666:
~$ socat UDP-RECVFROM:5252,ip-add-membership=224.10.10.10:eth0,reuseaddr,fork \
UDP-DATAGRAM:192.168.0.1:6666
Run two of the above with different destination addresses (reuseaddr option allows these to be run on the same machine).
Related
I have been experimenting with using tc, tc-nat and tc-pedit to perform stateless nat operations. My goal is to mirror packets from one interface (eth0) to another (eth1), but I also want to change the destination IP, and destination MAC, so the packets can be delivered to another host.
Host A [Eth0 - > Eth1 (change IP dst, change MAC dst)] -------> HOST B
Because I have other applications listening on Eth0, I can't perform either tc-nat or tc-pedit on the ingress/egress on Eth0. So this is what I did
Create a dummy interface
Mirror packets from Eth0 to dummy interface
Run tc-nat (to change destination IP) on egress side of dummy, pipe into tc-pedit (to change destination MAC), and pipe to mirror to Eth1.
The above contraption works as expected, but the performance is terrible (particularly when compared to a libpcap based application such as tcpbridge).
I started this approach hoping to achieve better performance in kernel space vs libpcap based application in user space. I'm curious is there a better way.
I have two programs.
Program 1. This program creates one socket per network interface, sets the default multicast interface ID for this socket and bind it to the "interface_addr:some_port". Program listens its sockets and process received data.
Program 1 was tested and it receives multicasts from network devices.
Program 2. This program creates one socket per network interface and sends multicast requests and process replies.
Program 2 was tested - it receives replies for multicast requests from network devices.
The problem is that when both programs runned on the one host program 1 not see requests from program 2, but Wireshark shows the packets from program 2.
OS: Windows 7.
What I'm doing wrong?
You don't need multiple sockets. Bind a single socket to INADDR_ANY, and join the group via each interface in turn.
The problem was solved. There is only need to turn on option MULTICAST_LOOP both on the client and server
I am struggling with switching between multiple live streams. For example, I have five live streaming servers streaming(HTTP or RTSP) and I want to put some broker between those (five) streaming sources and destination so that output to the destination would be one video streaming (later I may change the streaming source again using switch). Broker plays role of switcher, My question is, is there such open source "switcher"? Or how this technology works?
here is link to similar question but I want some open source or some brief guidance about how it could be implemented: http://forums.creativecow.net/thread/117/858680
Thank You in advance
That answer can be an archive for the researchers
First Suggestion or Solution(Multicast Router)
You can use a Router or L3 Switch which is support IGMP protocol. That Router or L3 Switch must support IGMP protocol you can structure multicast IP address. You can configure L3 to switch all streaming. Multicast Ip address works within 224.0.0.0 to 239.255.255.255 and works based on device' mac address. You can create different multicast Ip address for the different type of switching scenarios. After finished Router or L3 Switch configuration, you only change IP address to switch streaming into your program. (I didn't mention Broadcast. Broadcast send data to all points. Multicast send data to certain points.)
Second Suggestion or Solution(Programming)
I am using Vlc.Dotnet wrapper for using the Vlc and libvlc libraries. It's open source. RTSP streaming is based on IP address and port number. I don't know any open source switch but you can write one of them for you with use Vlc.dotnet wrapper. You build 5 Streaming server and 1 control server. The Streaming Server's destination should be Control Server's IP. and you can control all data from control server with your basic switch program.
5 Streaming Servers : Sends data to Control server
1 Control Server : Controls and Switches data
I prefer to use Router or L3 Switch for make that. Because it's easier.
Is there a way to find out the IP address of a device that is directly connected to a specific ethernet interface? I.e. given one host, one wired ethernet connection and one second host connected to this wired connection, which layer or protocol below IP could be used to find this out.
I would also be comfortable with a Windows-only solution using some Windows-API function or callback.
(I know that the real way to do this would probably via DHCP, but this is about discovering a legacy device.)
Mmh ... there are many ways.
I answer another network discovery question, and I write a little getting started.
Some tcpip stacks reply to icmp broadcasts.
So you can try a PING to your network broadcast address.
For example, you have ip 192.168.1.1 and subnet 255.255.255.0
ping 192.168.1.255
stop the ping after 5 seconds
watch the devices replies : arp -a
Note : on step 3. you get the lists of the MAC-to-IP cached entries, so there are also the hosts in your subnet you exchange data to in the last minutes, even if they don't reply to icmp_get.
Note (2) : now I am on linux. I am not sure, but it can be windows doesn't reply to icm_get via broadcast.
Is it the only one device attached to your pc ?
Is it a router or another simple pc ?
To use DHCP, you'd have to run a DHCP server on the primary and a client on the secondary; the primary could then query the server to find out what address it handed out. Probably overkill.
I can't help you with Windows directly. On Unix, the "arp" command will tell you what IP addresses are known to be attached to the local ethernet segment. Windows will have this same information (since it's a core part of the IP/Ethernet interface) but I don't know how you get at it.
Of course, the networking stack will only know about the other host if it has previously seen traffic from it. You may have to first send a broadcast packet on the interface to elicit some sort of response and thus populate the local ARP table.
Windows 7 has the arp command within it.
arp -a should show you the static and dynamic type interfaces connected to your system.
Your Best Approach is to install Wireshark, reboot the device wait for the TCP/UDP stream , broadcasts will announce the IP address for both Ethernet ports
This is especially useful when the device connected does not have DHCP Client enabled, then you can go from there.
You can also get information from directly connected networking devices, such as network switches with LDWin, a portable and free Windows program published on github:
http://www.sysadmit.com/2016/11/windows-como-saber-la-ip-del-switch-al-que-estoy-conectado.html
LDWin supports the following methods of link discovery: CDP (Cisco Discovery Protocol) and LLDP (Link Layer Discovery Protocol).
You can obtain the model, management IP, VLAN identifier, Port identifier, firmware version, etc.
Summary: I'm trying to create sockets to pass data between two physical interfaces that exist on the same machine, and Win32 sockets always forwards the traffic directly in the kernel instead of pushing through the physical interfaces. Is there any way to disable this behavior, perhaps through device settings, registry tweaks, routing table shenanigans, or socket options? We're using Windows XP SP3.
Some background. I'm attempting to build some completely automated IP tests to exercise our custom IPv4 equipment. We have a large lab of Windows XP machines, and individual physical ethernet interfaces for each device we're connecting to. Our devices are effectively ethernet routers each with their own IPs.
We need to send data out our lab machines, through our devices, then back into the same computer. We will be sending Unicast and Multicast UDP, TCP, and broadcast IP traffic through the devices.
We want (and likely need) the traffic to originate on the same machine it is destined to.
To do this, we configure two separate NICs each with their own IP on their own subnet, for instance NIC #1 with 10.0.0.1/24 and NIC #2 with 10.0.1.1/24. Our devices then act like simple passthrough routers, and have two interfaces, one on the 10.0.0.0/24 subnet, one on the 10.0.1.0/24 subnet, which they just forward packets back and forth from.
To generate our data, we'd like to be able to use Win32 sockets, since it is well-understood, well-supported, what our customers are using, and would probably be the most rapid approach. Packet injection is probably feasible for UDP and broadcast IP, but very likely not so for TCP. I'd entertain ideas that used packet injection, but would strongly prefer standard Win32 sockets.
As stated in the summary, the packets never leave the machine. I've googled like a madman and I've not found much. Any ideas?
Use Windows' command-line ROUTE utility. You can configure it so any IP packet sent to a specific IP address on a specific Subnet gets sent to another IP/device. For example:
route ADD <NIC_1_IP> MASK <NIC_1_SUBNET> <DEVICE_IP_CONNECTED_TO_NIC_2> METRIC 1
route ADD <NIC_2_IP> MASK <NIC_2_SUBNET> <DEVICE_IP_CONNECTED_TO_NIC_1> METRIC 1
Alternatively, if you know the index numbers of the NIC interfaces, you can specify them instead:
route ADD <NIC_1_IP> MASK <NIC_1_SUBNET> METRIC 1 IF <NIC_2_INTF>
route ADD <NIC_2_IP> MASK <NIC_2_SUBNET> METRIC 1 IF <NIC_1_INTF>
This way, whenever a packet is sent to NIC #1's IP, the packet goes to the device connected to NIC #2, which will then pass it on to NIC #1. And vice versa for packets sent to NIC #2's IP.
For instance, this is a useful technique for allowing WireShark to capture local IP traffic if the PC is connected to a network with a router. Packets from one local IP/Port to another local IP/Port can be bounced off the router back to the PC so they travel through physical interfaces that WireShark can monitor (WireShark will see duplicate copies of each local packet - one outbound and one inbound - but you can filter out the duplicates).
Winsock is always going to bring the packet data up into the kernel space and deal with it there. Thats the whole point to a generic API is that any device is dealt with at the same "layer". If you want to stick with Winsock, I don't believe you can (or would want to) work around this behavior.
You can remove some of the buffer copying with TransmitPackets or TransmitFile, but not between two device interfaces.
That being said, are you having a performance issue with the additional buffer coping that Winsock performs? Security concerns?
How about running the endpoints of your tester inside of distinct virtual machines? Then you need only a single piece of hardware, but you'll have separate TCP/IP stacks that don't know each other are local (and most VM solutions pass the packet straight through the host unchanged, I don't think the host is going to grab the packet and send it straight to another VM unless you configure bridging between VMs... but you'll bind each VM to a different physical network adapter).