I have a raspberry pi set up with Wireguard (via pivpn) inside my home network and a Windows client trying to connect to it. When I connect from the Windows machine, the logs show timeouts when attempting to handshake with the server. When running wg show wg0 on the Linux server, I see the Windows peer address is updated and the server received some data, and also tried to send data back. However, the endpoint for the Windows peer is incorrect.
Windows client log:
Handshake for peer 1 (<home_router_ip:port>) did not complete after 5 seconds, retrying (try 3)
Sending handshake initiation to peer 1 (<home_router_ip:port>)
Handshake for peer 1 (<home_router_ip:port>) did not complete after 5 seconds, retrying (try 4)
Sending handshake initiation to peer 1 (<home_router_ip:port>)
The Windows client shows
Transfer: 0 B received, 296 B sent
On the raspberry pi server, wg show reveals:
peer: <windows client pub key>
preshared key: (hidden)
endpoint: <unrecognized ip address and port>
allowed ips: 10.10.10.3/32
transfer: 3.90 KiB received, 2.43 KiB sent
Any thoughts on how to debug or what might be going on?
Details of the network setup (diagram):
The Windows client is connected to an iPhone hotspot via cellular network, thus simulating if I were to connect my Windows client to a public wifi.
My home network actually has 2 routers connected in serial. The first router connects/authenticates with the ISP. The second router connects to the first router and provides wifi in my house. The raspberry pi is connected to the second router.
Other things I tried:
I connected the Windows client to my home network (same network as my raspberry pi), and activated the VPN. I was still unable to receive packets from the server, but this time the Windows peer endpoint shown on the pi server was correct (it was the public ip of the router). I don't understand why traffic couldn't be routed in this case.
tcpdump -i wg0 on the pi server never shows anything, though wg show always seems to get updated when my Windows client connects, so I assume there's some communication that's getting through.
Related
I have a client that sends 115bytes of data periodically and a server that responds with 1131 bytes of data. However, after while the client stop receiving data. The client is actually a mobile modem with its own software and the server is run on ubuntu 16.04 LTS.
From wireshark I see that the mobile informs server of not receiving a previous packet and so the server starts re-transmitting the previous packet. But the client does not acknowledge this re transmission.
Any idea as to what might be happening here.Wireshark snapshot
192.172.0.2 is the IP of the client (Mobile) and 172.17.1.3 is the IP of the server.
I'm trying to send UDP packets over the t-mobile NB-IoT network using AT-commands on a SIM7020E chip. I used the product wiki as reference. The starter version of the sim card I have doesn't support TCP, but I'm planning on using that later if I can succesfully communicate using UDP.
I created a UDP-socket on a Raspberry Pi using "nc -u -l 9999". I set an A-record on my hosting provider to refer dev.mydomain.com to the IP address of the Raspberry Pi. I verified the portforward and A-record settings by sending UDP packets from my laptop on another network using "nc -u dev.mydomain.com 9999" and typing some teststrings, so this all works.
On the 4G chip I use the following AT-commands:
// Check network
AT+CSQ
+CSQ: 21,0
AT+CGREG?
+CGREG: 0,5
AT+COPS?
+COPS: 0,2,"20416",9
AT+CGCONTRDP
+CGCONTRDP: 1,5,"iot.t-mobile.nl","x.x.x.x.255.255.255.0" <-- crossed out my ip
// Create UDP socket
AT+CSOC=1,2,1
+CSOC: 0
// Connect socket 0 to the listening port on the Raspberry Pi
AT+CSOCON=0,9999,"dev.mydomain.com"
OK
// Send "test"
AT+CSOSEND=0,0,"test"
At this point I expect to see "test" appear in the command line on the Raspberry Pi, but nothing happens. In the T-mobile portal it shows a PDP-context is successfully activated.
Also, setting the APN manually with AT*MCGDEFCONT="IP","iot.t-mobile.nl","username","password" doesn't work.
Did you work this out Hans? I was plodding along with a SIM7020E following https://www.waveshare.com/wiki/Pico-SIM7020E-NB-IoT code examples. Was successfully sending HTTP GETS to a server (without having to use micropython's wretched urequests lib) via the CHTTPCREATE/CHTTPCON/CHTTPSEND AT cmds, that seem to be be able to send packets over LTE to a server without specifying TCP/UDP etc or using a socket. Maybe give it a try?
Sadly I got the bright idea of trying an 'AT+POWD=1' cmd over the uart (was supposed to power the 7020E down) & now the module now does nothing but echo AT cmds (still auto connects to the LTE network & slow flashes the network led, just won't do anything else.) Real shame, nice little module otherwise.
I have an IoT device (most likely across NAT), which should communicate with server (on internet), and the server should be able to send commands to the device. Here's the high level communication details:
IoT device will send KeepAlive packet from port 9000 (say) to the server on a port 8000 (say). The server now has the port and IP (say Cp and Cip) which it could use to start a connection back with IoT device if needed.
Server is obviously listening for connections on port 8000. So Server has a server-socket to listen to IoT device's keepalives
The KeepAlive packets are sent periodically, and the connection are closed once the server returns OK. This is to ensure a socket is not kept open, saving resources on both server and IoT device.
Now, say I want to send some command to the IoT device, in that case, I want to open a socket connection from the Server on port 8000, and send packet to Cip, Cp.
The IoT device should receive this packet on its port 9000. For that to happen, the IoT device should open a server socket to accept these connections.
As we can see, both client and server have to open the server socket on a particular port, and occasionally there's a requirement to create a client socket on that port to send some data.
Would TCP work with above scenario? I'm just confused if Client socket and Server Socket could be bound to the same port?
Please suggest
EDIT 1:
I deliberately have chosen above design since keeping IoT device to server connection open all time does not scale. Say I have millions of IoT devices on the field, I'll need to load balance the connections now.
The server to IoT device (backward) connection is only to ensure the commands are immediately send. The forward connection (IoT device to server) is only created to send the keepalives. It would be done periodically (may be 5-10 mins apart)
EDIT 2:
The reason for a fixed port (8000) is this: The NAT opens up hole for reverse communication only from the destination port where the keepalive packet was received. So the reverse packet can be sent from a port X on server to IoT device only if a packet had been received from IoT device on that port.
I have chosen QuteCom SIP client for windows to chat.I have installed and configured the account with my public server. My SIP server is kamailio.The connection to the server is not established. The application is connecting to the server for a long time.
Any help is appreciated.
If looks like keep connecting, then I guess the SIP messages don't get to the server.
You can install Wireshark to monitor traffic on windows host on port 5060 (the SIP port) in order to see if SIP messages are sent to the server.
On server, you can install ngrep for the purpose of seeing if traffic from the phone comes there. The command would be like:
ngrep -d any -qt -W byline port 5060
If you don't see traffic coming to the SIP server, then might be a firewall or an ALG between the client and the server, or, a firewall even on client host or server itself.
If it is something in between (not on client host or server), then you should try to use TCP or better TLS.
Note that if you have the firewall on the server, you will see the SIP packets coming on the network, but they will be dropped by the kernel before getting to application layer. Typically on Linux you can see the firewall rules with:
iptables -L
If the SIP packets come to the server, then set debug=3 in kamailio.cfg, restart kamailio and watch the syslog file (e.g., /var/log/syslog or /var/log/messgaes) for kamailio-specific debug messages -- you should get hints of what happens during processing.
I'm working on 2.6.15 kernel running on a cisco IPTV. When the box is coming up, the DHCP client hangs up. The reason for this is that the DHCP client does not get fetch the broadcasted DHCP offer message.
When I read /proc/net/dev file, it shows that ethernet device (eth0) has not received any packet. I then ran tcpdump on the box and it also shows that no packet is been received on the ethernet interface.
Then I ran wireshark on the test PC (on which DHCP server is running), it shows that a DHCP offer message is broadcasted by the DHCP server.
This DHCP client and server are working fine with other boxes so there are less chances that these programs have any issues. There must be an issue in the ethernet drivers.
I'm really confused. How should I proceed to this problem. Please help me.
Maybe you can start by checking whether the DHCP client is sending out a discovery.
The DHCP handshake goes like this:
client discovery,
server offer,
client request,
server ack
(Wikipedia has the steps of DHCP)
The next thing you can check any DHCP related settings on the router.
Is the DHCP client on the same subnet/vlan as the server? If not, would the router need a certain configuration to relay to/from the DHCP server subnet/vlan?