I have a Windows service running on a multi-homed Windows 7 machine communicating via UDP to a machine on the local network. This works fine, except sometimes during Windows startup the network traffic is temporarily (30 seconds) being routed to the default gateway, resulting in UDP packet loss. This packet loss is not necessarily a problem, but leads to an unnecessarily long startup time of the application.
The service binds to the socket using INADDR_ANY. Now when I change this to bind to the IP address of the control network NIC (192.168.32.1) I don't observe the problem. However I don't understand why the binding matters in this situation, and also I don't understand why the problem is there only temporarily. Do any of you have an explanation for this?
Besides my curiosity to find the root cause of this issue, I would also like to get an answer to this question so I can remove the bind to the specific IP address from my code. This decouples my application code from the network layout.
Network details:
Machine A, Windows 7, two NICs:
NIC #1 (ext network): 192.168.116.x/23 (DHCP), gateway 192.168.117.1
NIC #2 (int network): 192.168.32.1/26 (fixed)
Machine B, VxWorks, one NIC:
NIC #1 (int network): 192.168.32.16/26 (DHCP, assigned by Machine A)
When using INADDR_ANY, you bind your socket to the default IP address - the one with the lowest interface address. From the symptomps you are describing, it seems like this interface is not yet configured during startup, which makes sense.
The question is, why do you bind sending socket to any address at all. Implicit binding during send should be OK for you, I imagine?
Related
I need to create a TCP session "manually", without using the connect() function. I have tried to use RAW sockets. But in this case, I only get copies of the incoming IP packets. The original incoming packets slip through to the kernel and it generates an ACK response packet that damages my protocol.
Next, variant 2, I can write a virtual eth interface driver (kernel module) and route incoming traffic to it using iptables. But there is a patched non-original (non vanila) kernel on the machine. Normal linking of the module with the kernel is not possible.
Variant 3. I also tried not to assign an IP address to the NIC interface. In this case, the network TCP/IP layer module in the kernel is not activated and it is possible to generate and receive arbitrary IP packets on the link (ethernet) layer using the PF_PACKET socket domain type in the socket() function. But at this time, any other applications using the TCP/IP protocol can’t work.
How can this problem be solved in other ways?
It would be nice if it were possible to intercept packets going from the network interface to the kernel, that is, intercept the SKBuf buffer. But I don't know how to realize it.
Apparently you are trying to create a tunnel. Instead of trying to hijack an existing interface, the proper way to create a tunnel is to create a new interface, using a kernel module or TUN/TAP. However, tunnels are normally intended to receive traffic generated on the machine which runs the tunnel software, or at least routed through it. That means you will also have to set up the kernel to route the traffic to your tunnel.
You can create a new interface as a TUN/TAP interface. It is like a virtual ethernet driver except you don't need to write a new kernel module. It is designed for tunnels (hence the name).
The difference between TUN and TAP is that a TUN interface is an IP interface that receives IP packets from the kernel's IP routing system, and a TAP interface receives Ethernet packets (which may contain IP packets) so it can alternatively be part of a bridge (a virtual Ethernet switch - which only looks at the Ethernet header, not the IP header).
I think for your scenario, you will find it easiest to create a TAP interface, then create a bridge (virtual Ethernet switch) between the TAP interface, and the interface which the other host is connected to. Neither one needs an IP address - the kernel will happily pass Ethernet-layer traffic without attempting to process the IP information in the packet. Your tunnel software can then emulate a host - or tunnel to an actual host - or whatever you want it to do.
Or in visual form:
If you want the host to also be able to talk to the machine running the tunnel software - without going through the tunnel software - then you may choose to put an IP address on the bridge.
Before I proceed, I'd like to mention that I did try to research this topic on the internet, but I still need clarification.
Let's say I have two Linux machines connected to a switch (and only to a switch). Machine A has an IP address of 10.0.0.1 and machine B -- 10.0.0.2. I used nmcli command to set the IP address and create an ethernet interface for each machine. Everything works as expected.
Now, the confusing part is how machine A can find machine B and vice versa? I'm using the following command to connect from machine A to machine B:
ssh userB#10.0.0.2
And it works, even if this is the very first data transmission. This surely means that machine A somehow already knew the machine's B MAC address; otherwise, the frame wouldn't find its way to machine B. But how? Since the IP address is meaningless to the switch (Level2), why when I do ping 10.0.0.2 or ssh 10.0.0.2, it still works?
Probably the ARP cache was already populated. Maybe there was a grations ARP broadcast:
Every time an IP interface or link goes up, the driver for that interface will typically send a gratuitous ARP to preload the ARP tables of all other local hosts.
If not, most likely an ARP request/reply was happening right before the first ping. Check the arp command or ip neigh.
In general I suggest you use Wireshark to explore what's going on, or something like tcpdump -n -i eth0 not ssh if your are working remotely (note the -n to prevent name resolution). You can also record traffic with tcpdump -s 9999 -w output.pcap and view it later in Wireshark.
If you sniff network traffic on a third PC, keep in mind that switches will not send traffic to all ports when they have learned where the destination is. Some switches allow you to configure a mirror port to observe all traffic to or from a certain port. Either way you should always be able to observe ARP requests as they are broadcast.
basically, when the first packet reach to the switch ( virtual or physical switch ), the switch will populate arp broadcast packet for the sake of getting all devices mac and ip addresses. so even though ip addresses seem meaningless to switches ( cause they're layer 3 concept but switch is for layer 2 ), switches still need those data to process the packets. because this is how we, as human beings, interact with computers for transmitting data by using ip addresses.
when you ping a device, like 10.0.0.2, the switch will search in it's arp table and find the corresponding mac address and also the interface for reaching to the destination.
the best way to comprehend the whole process is to capture the data using wireshark or even implementing a simple topology in softwares like cisco packet tracer.
This might be a bit weird to explain, but I'll try my best.
I have a Lua program that's intended to serve some data through the network. Specifically, the internet. The data the program is actually transmitting are only strings stored within UDP packets. Generalized, this is how the program operates:
The first client launches the program and specifies that they are the 'host' of the connection. The program opens a connection on UDP port 6000 and the main loop listens for any packets received on said port.
The second client launches the program and specifies that they are to connect to the 'host' on port 6000. The user enters the IP, and the client opens a UDP connection using a random port between 6050 and 7000
When the client successfully connects to the server, they send a 'connection' packet, simply containing a '202 OK' string. The 'host' receives this and registers the new client
Now that the connection has been initialized, the programs can send data between each other using the registered data.
Now, on a local network this program works fine. The purpose of the 'host' mode is to have multiple clients connect to the host and have the host relay packets from one clients to all the currently registered clients. Port selections are arbitrary and random port selection from the client was simply to allow debugging and testing from a single computer. This has been tested between two and more computers on a physical network, and worked successfully. However, when I attempt to run this over the internet it's a no go. I know that the ports are closed and that's why it's not working. But seeing as I'm going to be distributing this program (privately) I can't expect every person to open ports on their router (or know how to). Security is not currently a concern with the program, and should be disregarded in the current state. That being said, I recognise there's the potential for a lot to go wrong with the use of this program through the network and I accept that. Onto the main question, how can I have the host and client communicate over the internet without having to open ports?
I'll elaborate - for example, browsers. Although the technology is quite different to what I'm doing, it's easier to paint a picture - the browser requests data from a web server, and it gets sent back to the client. But wait, if the router is in it's default state (I hope) all the ports are closed? So how does the client receive this data if the port is closed?
I hope this makes some kind of sense and I don't sound like a complete fool.
I managed to find some suitable libraries and utilities to be able to communicate through the internet (NAT traversal is now a term I am familiar with), those libraries being that supplied by NMAP. These libraries include an implementation for STUN in LUA, among HEAPS of other useful networking-related libraries and scripts.
To actually answer my own question (very simply), the clients and servers are behind what's known as a NAT gateway. Due to the limitations of addresses of IPv4, NAT gateways were implemented to bypass this limitation of IPv4 (a total of about 4.2 billion addresses) by separating the clients' internal network from the external network - in this case the internet. The NAT is supplied with a single IP address, and the NAT then supplies all of its users within the internal network with an IP respective to the network they're on. As such, the devices cannot directly be accessed without forwarding connections from the NAT gateway (generally the router) to the client. However, when using UDP connections the NAT gateway opens a port for the purposes of this connection which gets closed after the connection dies. This port that is opened differs from what is specified by the client when they open the connection, which is where the STUN methods come in. STUN allows the host to find the port that the client is connecting from and send data back to this port so the user can receive it. Bear in mind this is an EXTREMELY simple explanation of how the technology works, and I'd suggest reading up on the Wiki and some of the Request for Comments for STUN.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 7 years ago.
Improve this question
Very short qustion. Lets say user1 is connected to internet and running a http server # local. he needs to set port forwarding to work this. redirecting all incoming requests from public ip to local ip's port 80.
my doubt is that, User1 opens mozilla firefox , lets say, port 12343 , assigned by the os.
from this, (192.168.0.14:12343) to google.com:80... sometimes our router changes the incoming port to another port # NAT . clear..
My question: is there is any port forwarding set at the router to handle to route the packet.. ie, requests from google:80 to :12343 . plz correct me if am wrong at any protocol suite layers. i am new to this.
When connection is established through NAT, NAT maintains mapping between inside port and outside port. That is, when the packet comes from outside to the port 54321, NAT knows to forwward it to internal network IP 192.168.0.1., port 12345.
To explain further, let's dwell into details. Let's talk about transparent NAT. Transparent NAT's are ones which do not require any special configuration on locla software (unlike HTTP proxy servers, for instance). They usually serve as network gateways, so that OS knows to route network trafic to such a gateway (almost all home routers work in this mode).
When someone opens web page from desktop - local address 192.169.1.1, local port 12345, remote address stackoverflow.com, remote port 80 - OS directs trafic to network gateway (192.168.1.0).
Gateway sees the trafic as coming from 192.168.1.1, port 12345. On the packet, it replaces 192.168.1.1 with it's outside IP (say, 2.2.2.2) and gives it a port - say, 54321. It also creates an entry in it's mapping tables, indicating that all trafic incoming from outside for port 54321 is to be forwarded to 192.168.1.1, port 12345. StackOverflow server sees the trafic as coming from gateway, and responds back to the gateway address and port. Gatewat sees response, consults mapping table and forwards it to the local machine, where it is seen by the browser - and thus my answer is displayed on your screen.
I think there is nothing to do with NAT here. NAT just translates the internal local address(like 192.168.1.1) to an external global address(like 139.130.4.5). I hope you have adequate knowledge on OSI model. Let me explain it. When a packet reaches the transport layer,it is assigned a random port number(ranging from 0-65535),either TCP or UDP, by the OS. However, the OS can only port numbers from 49152 to 65535, as several ports are registered or is used for some specific process. A port is used to identify a service or a process. After adding port number, the packets are given to the network layer, which adds the source address and destination address of the packet. Switching is a process that happens in the network layer. This switching mechanism is responsible for the source to destination delivery of packets. Internet uses packet switching. When you are sending a packet in this switching mechanism, the packets get routed to several switches between the source and destination. Every packet that is sent through these switches are routed based on a switching table or routing table. This table contains details such as the MAC address and a physical port of the switch through which the packet is received and sent.
This is the only port forwading that happens inside a router or a switch. Delivering the packet to a specified MAC address is the only duty of a switch.
Every packet you sent through a router goes to its destination based on the routing table. Several protocols work in this layer to make the source to destination delivery possible and some of them are ARP,IP,RARP etc.
Additionally, a packet is encapsulated with information from top layers as it moves down the layers. So, at the receiver side, the packet will comes at network layer and then gets decapsulated and it is moved to the transport layer, which then decapsulate the packed and send it to the corresponding process base on the port.
So, what I told is that there is no connection with a process (port number) and the physical port of the router. It is true that the packet travels through the physical port of the router but it doesn't know anything about the process that sends the packet.
For example, when you make an ssh connection, you are connected to port 22. What happens then? On a very high level brief overview, I know that if port 22 is open on the other end and if you can authenticate to it as a certain user, then you get a shell on that machine.
But I don't understand how ports tie into this model of services and connections to different services from remote machines? Why is there a need for so many specific ports running specific services? And what exactly happens when you try to connect to a port?
I hope this question isn't too confusing due to my naive understanding. Thanks.
Imagine your server as a house with 65536 doors. If you want to visit family "HTTP", you go to door 80. If you were to visit family "SMTP", you would visit door no. 25.
Technically, a port is just one of multiple possible endpoints for outgoing/incomming connections. Many of the port numbers are assigned to certain services by convention.
Opening/establishing a connection means (when the transport protocol is TCP, which are most of the “classical” services like HTTP, SMTP, etc.) that you are performing a TCP handshake. With UDP (used for things like streaming and VoIP), there's no handshake.
Unless you want to understand the deeper voodoo of IP networks, you could just say, that's about it. Nothing overly special.
TCP-IP ports on your machine are essentially a mechanism to get messages to the right endpoints.
Each of the possible 65536 ports (16 total bits) fall under certain categories as designated by the Internet Assigned Numbers Authority (IANA).
But I don't understand how ports tie into this model of services and
connections to different services from remote machines? Why is there a
need for so many specific ports running specific services?
...
And what exactly happens when you try to connect to a port?
Think of it this way: How many applications on your computer communicate with other machines? Web browser, e-mail client, SSH client, online games, etc. Not to mention all of the stuff running under the hood.
Now think: how many physical ports do you have on your machine? Most desktop machines have one. Occasionally two or three. If a single application had to take complete control over your network interface nothing else would be able to use it! So TCP ports are a way of turning 1 connection into 65536 connections.
For example, when you make an ssh connection, you are connected to
port 22. What happens then?
Think of it like sending a package. Your SSH client in front of you needs to send information to a process running on the other machine. So you supply the destination address in the form of "user#[ip or hostname]" (so that it knows which machine on the network to send it to), and "port 22" (so it gets to the right application running on the machine). Your application then packs up a TCP parcel and stamps a destination and a return address and sends it to the network.
The network finds the destination computer and delivers the package. So now it's at the right machine, but it still needs to get to the right application. What do you think would happen if your SSH packet got delivered to an e-mail client? That's what the port number is for. It effectively tells your computer's local TCP mailman where to make the final delivery. Then the application does whatever it needs to with the data (such as verify authentication) and sends a response packet using your machine's return address. The back and forth continues as long as the connection is active.
Hope that helps. :)
The port is meant to allow applications on TCP/IP to exchange data. Each machine on the internet has one single address which is its IP. The port allows different applications on one machine to send and receive data with multiple servers on the network/internet. Common application like ftp and http servers communicate on default ports like 21 and 80 unless network administrators change those default ports for security reasons