I write a simple server application. In that application, I created a server socket and put it into the listen state with listen call.
After that, I did not write any code to accept the incoming connection request. I simply waited for the termination with pause call.
I want to figure out practically that how many bytes are buffered in the server side if the connection is not accepted. Then I want to validate the number with the theory of the TCP.
To do that,
First, I started my server application.
Then I used "dd" and "netcat" to send the data from client to server. Here is the command:
$> dd if=/dev/zero count=1 bs=100000 | nc 127.0.0.1 45001
Then I opened wireshark and wait for the zero-window message.
From the last properly acknowledged tcp frame. the client side can successfully send 64559 byte data to the server.
Then I execute the above dd-netcat command to create another client and send data again.
In this case, I got the following wireshark output:
From the last successfully acknowledged tcp frame, I understand that the client application can successfully sent 72677 bytes to the server.
So, it seems that the size of the related buffer can change in runtime. Or, I misinterpret the output of the wireshark.
How can I understand the size of the related receive buffer? What is the correct name to refer that receive buffer in terminology? How can I show the default size of the related receive buffer?
Note that the port number of the tcp server is "45001".
Thank you!
I bought a Simcom (Sim7080G) module to use it for geolocation and send data over TCP. These modules are quite new on the market (it was first launched in mid 2019) and there is some weird functionning with it. I would like to know if people that use it struggle with the same problem.
My goal is to take GNSS (latitude/longitude) informations, and to send them over TCP.
Activate and take GNSS informations
AT+CGNSPWR=1
returns OK
AT+CGNSINF returns +CGNSINF: 1,1,20200517191239.000,4x.xxxxxx,6.xxxxxx,473.769,0.00,,0,,1.9,2.1,1.0,,7,,7.9,6.0
Connect to any TCP server
AT+CNACT=0,1 returns OK\r\n\r\n+APP PDP: 0,ACTIVE
AT+CAOPEN=0,0,"TCP",151.101.1.69,80 (151.101.1.69 is stackoverflow.com ip address)
--> Some time waiting (like +40s) and then:
+CAOPEN: 0,23\r\n\r\nOK
The code 23 means: 23 Remote refuse, but in my case the connection never reached the server.
Only GNSS or TCP can be used, but not both
What is weird about all of this, is the fact that I can connect on a TCP server, but this stops to work when I activate GNSS.
I sent an email to Simcom technical support.
After insisting that my problem be addressed by a Simcom engineer, I received an answer. I encouraged them to be more clear on their documentation because this information was nowhere (this module is pretty new so I think they missed it on documentation).
Hope to help somebody in the same way or not to do the same pricey error:
Hi Dardan,
"it is not possible to use GNSS and TCP at the same time"
This is known limitation for this module, as there are limitation for
LTE and GNSS part, they can not run simultaneously because they are
sharing part of RF components(SIM7070G low cost version of SIM7000G)
so it is time MUX for LTE and GNSS which means the GNSS performance
could not be good(if customer needs to send GNSS data to server in
very short interval such as <10 seconds), for SIM7000G LTE and GNSS
can work simultaneously without problem. so SIM7070G could be a good
solution for "parcel tracking" etc, which do not need the continue
navigation. please go for SIM7000G, thanks.
xxxx Sun
I found this issue some hours before read this post. My product publishs in AWS IoT MQTT broker; it works, but I need the GPS coordinates to be sent together in message. I'm a lot frustrated, because such problem should be said in Simcom's documents. My previous version was using sim7600g, more expensive, but works fine. I live in Brazil, everytime I need to test some different module I loose more than 1 month to buy from China or somewhere and arrive a new one to me. I tried to turn ON/OFF GNSS and the TCP conection in alternate way, but is too slow the process to reconnect on gsm network.
Ran into this as well. With MQTT it is possible to power down the GPS unit to be able to send and receive MQTT messages without reconnecting/subscribing to the broker again. I've made a 30 second interval to enable/disable the GPS unit and tested it with HiveMQ public broker. Receiving of position data every 60 seconds is possible with this setup, which might be sufficient for some applications. For the price, it has this is still a good module.
I receive no response for HTTP Get request for the http://httpbin.org/get URL. Following is the output using the AT Command Tester from https://m2msupport.net
Checking registration status...
AT+CREG?
+CREG: 2,1,"912","3D73",0
OK
The device is registered in home network.
AT+CGREG?
+CGREG: 2,1,"912","3D73",0,"1"
OK
The device is registered in home network.
Device is registered..
Check the network APN...
AT+CGNAPN
+CGNAPN: 0,""
OK
Network did not send APN to the device.
Activate the network bearer...
AT+CNACT=0,1
OK
+APP PDP: 0,ACTIVE
Set up the HTTP URL...
AT+SHCONF="URL","httpbin.org"
OK
Set up the HTTP body length...
AT+SHCONF="BODYLEN",1024
OK
Set up the HTTP header length...
AT+SHCONF="HEADERLEN",350
OK
Initiating HTTP connection...
AT+SHCONN
OK
Get the HTTP connection state...
AT+SHSTATE?
+SHSTATE: 1
OK
HTTP connection is successful...
HTTP get request...
AT+SHREQ="http://httpbin.org/get",1
OK
No reponse received..
For avoiding buffer overflow in FTP welcome message, what is the maximum size for it?
I know it could contain multiple lines, for example:
220-QTCP at fran.csg.stercomm.com.
220 Connection will close if idle more than 5 minutes.
but is there a specifications for how many rows or char is it suppose to contain?
Thanks,
There are generally no limits specified in FTP specifications.
Quoting RFC 624 section 5:
There is no specified maximum length of a TELNET command line,
TELNET reply line, user name, password, account, or pathname.
It refers to "TELNET lines" because FTP control connection uses the TELNET protocol format. Quoting RFC 959 section 2.2:
control connection
The communication path between the USER-PI and SERVER-PI for
the exchange of commands and replies. This connection follows
the Telnet Protocol.
I am creating a syslog formatted message according to RFC3164 and sending it to my linux default syslog server which is listining of port 514.
The message i am sending is
<187>Nov 19 02:58:57 nms-server6 %cgmesh-2-outage: Outage detected on this device
I open a socket, make a datagram packet and send this packet on that socket.
Now in the var/log/syslog.log which i have configured to receive all the syslog messages as
. /var/log/syslog.log
I am getting this extra hostname getting inserted by the server automatically as show below
Nov 19 02:58:57 nms-server6 nms-server6 %cgmesh-2-outage: Outage detected on this device
as you see nms-server6 is getting repeated twice while i am sending it just once...so somehow the server is inserting it by default..
can some one share some knowledge on this ?
Are you adding the hostname in your message? If so, I don't think that's necessary as the hostname will be taken from the packet - which would explain the duplication.
Also, as a side note - it's nice that you've added the %fac-sev-mnemonic: portion, but that is not a standard, it's used by Cisco devices.
Here's a link to a good whitepaper that covers Cisco Mnemonics (and syslog management):
Building Scalable Syslog Management Solutions:
http://www.cisco.com/en/US/technologies/collateral/tk869/tk769/white_paper_c11-557812.html
I'm working on an RDP client with a friend as a pet project and we're trying to get fast-path updates to work since rdesktop hasn't supported this so far. We're able to process around 20-21 fast-path PDUs after the handshake before decryption starts failing. This is because somewhere in there, the RDP server is encrypting 20 bytes and throwing off the RC4 keystream. If I consume 20 bytes from the client decryption keystream at the right time and place, all my fast-path updates are able to be decrypted. Unfortunately, this "right time and place" changes depending on the sequence of packets the RDP server is sending.
I was wondering 2 things:
Has anyone been able to successfully get fast-path updates working in their RDP client, open source or otherwise? Obviously, MSTSC doesn't count :-)
Has anyone seen this issue with the 20 bytes or know of any reason why it occurs?
Any help would be much appreciated.