I'm using a PXI 8109 running Pharlap OS.
I'm trying to use the second ethernet interface of my PXI to send UDP and TCP packets.
Here the configuration of my two ethernet interfaces:
eth0 (primary):
IP : 10.0.0.3
subnet mask : 255.0.0.0
eth1 :
IP : 192.168.10.9
subnet mask : 255.255.255.0
For UDP, I have no problems, packets are sent to the second interface as I want. I think it work because there is a "net address" input on the "UDP Open" VI so the system can choose the right interface.
For TCP, I use the "TCP Open connection" VI but there is no this kind of input. And it is not working : I assume the system is trying to use the primary interface but it can't route packets...
For information, my two networks are physically independant.
Can you help me finding out what's going on ? Is it possible to use TCP on the second ethernet interface ?
TCP open is meant to open a connection to another computer, if you feed a valid (in one of the two subnets) TCP address it should open a connection on that specific interface.
I assume you need to use the TCP listener function and according to this KB article, you can specify on which address you want to listen. So yes, you should be able to use a specific ethernet interface.
disclaimer: I am not sure if all this info is valid on Pharlap as well.
Basically, the decision which NIC to use is up to the OS and I believe that normally it would choose based on the subnet of the address you're trying to connect to and those of the NICs - I don't know what the IP address is (maybe it's in the subnet of the wrong card?), but the subnets of the NICs certainly appear to be different from each other (10.0.0.0 and 192...).
On Windows, I believe you can set the routing tables to have some more control of this (although I don't know if you would be able to force something to go through the "wrong" NIC), but I have no idea how much control you would have over this on Phar Lap. I would suggest some searching. Here are a couple of relevant links:
http://forums.ni.com/t5/LabVIEW/RT-How-do-I-use-two-independent-Ethernet-ports/td-p/721269
http://forums.ni.com/t5/LabVIEW/Communicating-through-two-ethernet-ports-on-the-same-computer/m-p/1509450#M565374
I finally solved my problem. This was not related to the TCP connection ...
I was using a property node "Value (signaling)" to trigger the TCP connection and it seems that this is not supported on RT Targets.
This is why it was working on localhost.
Thanks for the help anyway ;)
Related
I am sorry if its basics, but I did not find the appealing answer for it over the Internet.
Why only MAC is used to transfer the packet to a device ? MAC address is only obtained by ARP for a specific IP address. So, why not just let the routers maintain IP addresses of the neighbouring routers and route packets using IP addresses of routers instead of MAC addresses ?
Why not redesign the architecture, to only use IP address for routing as well as moving the packet in the data link layer too ?
Why do we need MAC addresses?" Why can't network devices such as the routers just send the packet to the next router using the router's IP address?
Note : I know that MAC address is used to identify the system in a network. But you see the source never knew the MAC address of receiver. All it knew was its IP address and MAC address of next hop.
I'm reading Data Comm and Networking by Forouzan ( Ed 5) and it says that even routers have an IP address. So why use the mac address at all. The router can store the IP address of the source and route it to the next router .
EDIT : The question that I was getting as suggestion to this one does not answer my query. There are multiple counter points and proof that I have presented here which could have been done which is not answered by the one which is suggested. So please read my question before making any assumptions.
What do you think makes more sense: Having one protocol like Ethernet handle all the layer 2 details so that its layer 3 payload doesn't have to care, or force IP, ARP, WoL, IPX, MPLS, SLPP, and dozens more implement it on their own? The whole purpose of OSI layers is that upper layers need not know all the lower layer's details and lower layers need need not support the upper layer's features.
MAC addresses are used for the layer 2 protocol which encapsulates a layer 3 protocol. If all the necessary features were embedded into IP, then you'd be leaving other protocols to re-implement layer 2 routing on their own. This would be wildly inefficient.
I was reading that in order to capture traffic for more than just my machine I need to put the nic into promiscuous mode. By default the nic seems to filter out the packets which are not meant for it.
My Question is : How come my nic even receive traffic that is not intended for it? Isn't my router supposed to route packets only to the computer for which it is meant?
Sorry - newbie here and this may be an absolute down votable question that I am asking.
I have heard that in case of wireless networks, the traffic takes multiple paths and the NIC combines these signals to form the original signal. So when a NIC sends something to the gateway it will send multiple signals and some if not all may even be captured by your packet sniffer.
Monitor mode also works like this
The short answer: It depends. :)
Wireshark Wiki: Ethernet capture setup should be of help to get you started.
We have about 30 clients connected to a single cable-modem/router (Fritzbox 6360). Some clients also connect to a TP-Link W-LAN Router which is also connected to the cable modem.
Sometimes the internet is very slow and we can see an continous upstream (6 MBit/s). Unfortunately we can not see which clients cause that traffic. The Fritz Box provides a functionality to capture network traffic and then analyze it with Wireshark.
Following interfaces can be captured by the cable modem:
Internet connection
Interface 0 ('internet')
Routing interface
Network interfaces
tunl0
cni0
lbr0
wan0
eth0
lan
erouter0
esafe0
And there is an option to launch DTrace (default parameters are)
-D -s -m -i256 -dect -dlc -c1 -c2 -c3 -c4 -c5 -nt3 -d2 -d3
We already captured different interfaces and tried to understand the data with Wireshark but without much success. What would be right way to see which Client is uploading Data at the moment?
In Wireshark, to get a list of IP addresses and what percentage of the trace each of the IP Addresses are taking up, go to Statistics->IP Addresses.. and click "Create Stat" in the box that pops up while leaving the the "Filter" option blank. You should be able to figure out which of your client ip is hogging up the most bandwidth with this.
For a visual comparison, click "Statistics->IO Graph", and in the second filter next to Graph 2, type "ip.src == x.x.x.x" (where x.x.x.x is the ip address of the uploader you suspect is taking up the most bandwidth) and click "Graph 2". This will give you a packets vs time graph. You can also filter out other ip addresses as well to display simultaneously in the same graph for comparison.
Edit: I would also suggest keeping an eye out for IPv6 addresses.
2 computers are in different subnets.
Both are Windows machines.
There are 2-5 IGMP-ready routers between them.
They can connect each other over multicast protocol (they have joined the same multicast group and they know about each other's existance).
How to establish a reliable TCP connection between them without any public server?
Programming language: C++, WinAPI
(I need a TCP connection to send some big critical data, which I can not entrust to UDP)
You haven't specified a programming language, so this whole question may be off-topic.
Subnets are not the problem. Routability is the problem. Either there is routing set up or there isn't. If they are, for example, both behind NAT boxes, then you're at the mercy of the configuration of the nat boxes. If they are merely on two different subnets of a routed network, it's the job of the network admin to have set up routing. So, each has an IP address, and either can address the other.
On one machine, you are going to create a socket, bind it to some port of your choice, and listen. On the other, you will connect to the first machine's IP + the selected port.
edit
I'm going to try again, but I feel like there's a giant conceptual gap here.
Once upon a time, the TCP/IP was invented. In the original conception, every item on the network has an IPV4 address, and every machine could reach every other machine, via routing, except for machines in the 'private' address space (10.x, etc).
In the very early days, the only 'subnets' were 'class A, class B, class C'. Later the idea of subdividing a network via bitmasks was added. The concept of 'subnet' is just a way of describing a piece of network in which all the hosts can deliver packets to each other by one hop over some transport or another. In a properly configured network, this is only of concern to operating system drivers. Ordinary programs just address packets over the network and they arrive.
The implementation of this connectivity was always via routing protocol. If you have a (physical) ethernet A over here, and a (physical) ethernet B over there, connected by some sort of point-to-point link, the machines on A need to know where to send packets for B. Or, to be exact, they need to know where to send 'not-A' packets, and whatever they send them needs to know where to send 'B' packets. In simple cases, this is arranged via explicit configuration: routing rules stuffed into router boxes or even computers with multiple physical interfaces. In more complex cases, routing boxes intercommunicate via protocols like EGP or BGP or IGMP to learn the network topology.
If you use the Windows 'route' command, you will see the 'default route' that the system uses to send packets that need to leave the local subnet. It is generally the address of the router box responsible for moving information from the local subnet to everywhere else.
The whole goal of this routing is to arrange that a packet sent from a.b.c.d to e.f.g.h will get there. TCP is no different than UDP, except that you can't get there by multicast or broadcast: you need to know the exact address of your correspondent.
DNS was invented to allow hosts to learn each other's IP addresses without having human being send them around in email messages.
All this stops working when people start using NAT and firewalls to turn off routing. The whole idea of NAT is that the computers behind the NAT box are not addressable at all. They all appear to have one IP address. They can send stuff out, but they can only receive stuff if the NAT box has gone to extra trouble to map them a port.
From your original message, I sort of doubt that NAT is in use here. I just don't understand your comment 'I don't have access to the network.' You say that you've sent UDP packets here and there. So how did you do that? What addresses did you use?
i was learning socket programming in unix using c/c++.
I am confused with one function call bind(params..).
Actually it takes the adreess structure "sockaddr_in" and we can create the structure in the following way
sockaddr_in.*** = somthing..
sockaddr_in..s_addr htonl(INADDR_ANY)
**Passing INADDR_ANY will alow to bind all local addresses**
My question is , why do we need to use "INADDR_ANY" ?
In my knowledge every machine can has only one unique IP Address. In this way there is only one address associated with the machien. Thye bind call should directly bind the socket to the single available address.
Please explain what are the different scenarios and why is it so?
A machine usually has an IP address for each connected network interface plus 127.0.0.1 for localhost (loopback). For example, a laptop might be connected to a wireless network as 10.0.1.25 and also to a wired network as 10.0.2.4. Servers often have an interface to an internal network as well as a public network.
It's possible for a machine to have more than one IP address, either because it has multiple network cards or through software. INADDR_ANY lets you bind a socket to all of the machine's IP addresses.
Not true. Most machines are Multi-Homed, that means, they have more than one IP address.
For example, the network address and 127.0.0.1.