I have a question about establishing a stable internet connection (IuPS_PS) between MS and our developed network core system using our home nodeB (HNB).
In our core system, we can see the the internet packets which are sent from MS to HNB and from HNB to the core system. I attached a screenshot of the wireshark log on the interface between HNB and core.
As you can see in this picture, the user query is server.hnb. Source IP (MS IP) is 10.250.0.114 and destination IPs are 172.60.3.154 (core IP) and 8.8.8.8 which we are set as DNS address in Activate PDP Context Accept (Activate PDP Context Accept is a message which is sent from core to HNB and from HNB to MS which contains some internet parameters such as DNS IPs, bit-rates, ... ). The protocol is GTP-DNS and the stacked layers are DNS / UDP / IP / GTP / UDP / IP. I attached the stacked layers in the following images:
Destination IP is 172.60.3.154
Destination IP is 8.8.8.8
Also, we know that to handle GTP packets, a GTP tunnel is required to listen to UDP port 2152. To do that, we use libgtpnl (osmocome project) and to establish a GTP tunnel, at first, we have to create a GTP interface using the following command of libgtpnl:
gtp-link add gtp1 --sgsn
where gtp1 is interface name. After executing the above command, we use netstat to display network connections and here is the result:
and every thing is OK. Finally, we add GTP tunnel using the following command of libgtpnl:
gtp-tunnel add gtp1 v1 100 1 10.250.0.114 172.60.3.154
where v1 is GTP version, 100 is the gTP-TEI field in RAB-Assignment Request (GTP tunnel configurations which is sent from core to HNB) and 1 is the similar filed obtained from RAB-Assignment Response (GTP tunnel configurations which is sent from HNB to core). Also, 10.250.0.114 is the MS IP and 172.60.3.154 is the core IP.
After receiving some packets from MS to core and using netstat, we see that Recv-Q (bytes in UDP port 2152 which are ready to read) is increased to a value more than 0, but the added GTP tunnel is not read the GTP packets and the gtp1 interface which we already added is empty in wireshark. What is the problem that GTP packets are not inserted in my GTP tunnel (gtp1)?
You want to handle GTP-U packets so your test machine is GGSN rather than SGSN, thus your git-link command is not correct, the parameter "--sgsn" must be removed.
The commands of libgtpnl on SGSN and GGSN are as similar as below:
SGSN:
gtp-link add gtp1 --sgsn
gtp-tunnel add gtp1 v1 100 200 1.1.1.1 2.2.2.10
GGSN:
gtp-link add gtp1
gtp-tunnel add gtp1 v1 200 100 1.1.1.1 2.2.2.2
2.2.2.2 is IP address of SGSN node
2.2.2.10 is IP address of GGSN node
1.1.1.1 is IP address of user/terminal
Related
I am running server and client in same system. TCP protocol is used for communication between them. In a scenario where client wants to send packet to server, will it go through network infra (i.e. router, internet etc) and come to server or will it manage transfer within system and ignore network.
If you are on the server, any communication you initiate to IP addresses also on the same server will never leave the server.
You can test by installing tcpdump then running from the console/keyboard/mouse:
tcpdump -n -i enp0s5 not arp
Do not generate network traffic. Try to ssh to your account on IP 127.0.0.1 (e.g. risner#127.0.0.1).
Also try to initiate ssh to another host on the network.
Nothing should show on tcpdump, so that indicates it is not leaving the machine.
I am using UdpSocket to create a server, binding to 0.0.0.0:serverport. I can get the source IP when a datagram arrives by using recv_from.
However, I need to get my local server's IP (destination IP) which the remote client contacted. I can see it in Wireshark but cannot obtain it via the API.
Motivation: I have 2 IPs from same network, eth and wlan. When a client contacts me on my wlan IP, in Wireshark I see the response UDP packet will have the correct port (same as request), but the source IP is the IP of my eth interface, thus the client will not receive the answer. Listening on just my wlan IP does solve the issue, but I want to listen on all interfaces.
I'm trying to make a TCP based communication to send a simple message "Hello" from one ESP8266 module to another using this document. I'm using 2 USB to TTL as hardware and Realterm as serial terminal.
I could do it when ESP8266 modules are connected to a router, sending AT commands as below,
Set the Server:
AT+CWJAP="AccessPointName","Password"//Join to your WiFi network
AT+CIPMUX=1//0 for single connection 1 for multiple connection.
AT+CIPSERVER=1,1336//Set as Server. 1 to open Server mode(0 to close). 1336 is port.
AT+CIFSR//Get IP address (STAIP 192.168.43.151)
Set the Client:
AT+CWJAP="AccessPointName","Password"
AT+CIPMUX=1
AT+CIPSTART=1,"TCP","192.168.43.151",1336//Set up TCP or UDP connection, the 4 parameters are id, type, adress and port.
AT+CIPSEND=1,7// Channel and number of bytes to send
//After issuing all previous command you will receive "OK". But afterAT+CIPSENDyou will receive a ">" as response.
Hello//send your Data
I want to connect both ESP8266 to each other without a router.
So I used these AT commands:
Server commands:
AT+CIPMUX=1
AT+CWMODE=3//set the module as a client and also an access point.
AT+CIPSERVER=1,1336
AT+CIFSR //Getting 2 ip address (APIP 192.168.4.1 and STAIP 0.0.0.0).
Client commands:
AT+CIPMUX=1
AT+CWMODE=3
AT+CWJAP="ESP1 SSID", "ESP1 PWD" //Connect to server
AT+CIPSTART=1,"TCP","0.0.0.0",1336 // I also tried APIP 192.168.4.1.
But when I send CIPSTART command I get ERROR message.
What's going wrong? What should I do?
In the context of a route entry, the 0.0.0.0 means the default route. In the context of servers, 0.0.0.0 means all IPv4 addresses on the local machine. If a host has two IP addresses, 192.168.1.1 and 10.1.2.1, and a server running on the host listens on 0.0.0.0, it will be reachable at both of those IPs. This type of communication is also known as WiFi P2P or Wifi direct. It should work properly with your commands! If problem persists try with different modules.
I changed modules and it's working now.
The Server Commands:
AT+CWMODE=3
AT+CIPMUX=1
AT+CIPSERVER=1,222
AT+CIFSR
/*the server response to CIFSR is:
+CIFSR:APIP,"192.168.7.7"
+CIFSR:APMAC,"a2:20:a6:10:50:2c"
+CIFSR:STAIP,"0.0.0.0"
+CIFSR:STAMAC,"a0:20:a6:10:50:2c"*/
The Client commands:
AT+CWMODE=3
AT+CWJAP="SERVER_SSID","SERVER_PASS"
AT+CIPMUX=1
AT+CIPSTART=2,"TCP","192.168.7.7",222
AT+CIPSEND=2,7
HELLO
When VPN is active, all the traffic seems to be tunneled through csctun0.
Using a VirtualBox I am able to set up a "network bridge" to eth0, which seems to completely ignore the manipulations made by Cisco's software. The VirtualBox directly connects to my local network and accesses local network devices and the internet directly.
I want to achieve the same with Docker containers, but the Docker's bridge seems to work differently.
What is necessary to let a Docker container bypass Cisco's tunnel like a VirtualBox does?
Edit:
As suggested by #NetworkMeister I tried to use "macvlan" and followed the instructions on http://hicu.be/docker-networking-macvlan-bridge-mode-configuration but fail when I trying to send pings to the local gateway:
# docker exec -ti container0 ping -c 4 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
64 bytes from 10.0.0.1: Destination Host Unreachable
64 bytes from 10.0.0.1: Destination Host Unreachable
64 bytes from 10.0.0.1: Destination Host Unreachable
64 bytes from 10.0.0.1: Destination Host Unreachable
--- 10.0.0.1 ping statistics ---
4 packets transmitted, 0 packets received, 100% packet loss
Docker's default bridge network allows you to NAT your containers into the physical network.
To achieve what you know as "bridged network" from VirtualBox, use Pipework or, if you are cutting edge, you can try the docker macvlan driver which is, for now, experimental.
One (ugly) solution would be to run your docker container with --net=host. That way your docker container doesn't have a network interface and has the same network access as any of your physical machine, it should work.
How do I set an IP address for a TUN interface on OSX? I cannot figure out how to set up an ip address for my interface without specifying a destination IP. I don't want to do that- I'm want to more or less build a tunnel to an arbitrary address at a later point in time. Prior questions which are unhelpful:
There's a question that has an unclear answer, so I tried following the reference.
This question sets a point to point ip address for a tun device, so it has a destination, which is exactly what I don't want.
On the page for osxtuntap it says:
ifconfig tap0 10.1.2.3 up
I cannot make this work on OSX 10.6 for a TUN interface:
$ sudo ifconfig tun0 10.1.2.3 up
ifconfig: ioctl (SIOCAIFADDR): Destination address required
Adding a netmask doesn't help- OSX seems to demand a destination address:
$ ifconfig tun0 10.0.0.1/24 netmask 255.255.255.0
ifconfig: ioctl (SIOCAIFADDR): Destination address required
For linux, I get how it works. According to this page, you open() the interface, and use the ip command, and do this, and I've done this before with zero issues:
$ ip link set tun0 up
$ ip addr add 10.0.0.1/24 dev tun0
All I want to do is the same thing that I can do in linux.
EDIT:
I'm writing a little UDP tunnel app. Like so:
tun1 -> udp app #1 -> udp tunnel -> udp app #2 -> tun2
If the udp apps are on different computers (let's say local and remote), I'd like to associate their respective tun devices with an ip address, so I can send a packet from local to remote via the tunnel by sending the packet to the ip address of the tun device on the remove machine.
To borrow more from the linux tutorial, the author sets up a tun device on local and remote, associates ips, and runs a simple tunneling app, and then pings the other end of the tunnel:
[remote]# ip link set tun3 up
[remote]# ip addr add 192.168.0.2/24 dev tun3
[remote]$ ./simpletun -i tun3 -s
# server blocks waiting for the client to connect
[local]# ip link set tun11 up
[local]# ip addr add 192.168.0.1/24 dev tun11
[local]$ ./simpletun -i tun11 -c 10.2.3.4
# nothing happens, but the peers are now connected
[local]$ ping 192.168.0.2
By default, tun devices operate in the layer 3 mode, aka point to point. You're asking for layer 2 mode which more closely resembles a generic Ethernet device. Linux calls these tap devices. In OpenBSD you can switch a tun device into layer 2 mode with "ifconfig tun0 link0". The Macintosh tuntaposx driver mimics Linux' device schism; open a tap device instead.
You might want to review https://community.openvpn.net/openvpn/wiki/BridgingAndRouting to determine if you really want tap devices. They add a little overhead. If you just need two boxes to pass IP packets between each other and no bridging or broadcasting to a larger subnet, point to point should be sufficient.
For example, if you have two machines, one we label "local" with a LAN IP address like 192.168.0.12 and another we label "remote" with a LAN IP address like 192.168.1.14, you can assign tunnel IP addresses thusly:
ifconfig tun0 inet 10.0.0.1 10.0.0.2 up
on the local system, and:
ifconfig tun0 inet 10.0.0.2 10.0.0.1 up
on the remote system. Note the reversed perspective on the remote machine. Do not set your point to point addresses to anything on an existing subnet; it will not route properly.
I can't stress this enough: read and re-read the manual pages ("man ifconfig" and "man tun", probably others) until they make sense. My ifconfig examples above may differ slightly from your operating system.
And for another perspective you might look into GRE tunnels as their functionality mirrors what you describe for your program. However, GRE is likely not viable in today's TCP-centric networks nor is it a good idea due to major security issues.
If your goal is to circumvent an overbearing firewall, be aware that many such firewalls block UDP (and especially GRE) packets. In such a case, try SSH interface tunneling to set up tun/tap interfaces and forward packets. You get encryption and optionally compression as well. :)