Custom Query (106 matches)

Bug report from Jun Shih (Jun.Shih@…)

=========== first message =================== I have seen the following ntrip server reset condition in my log: [02/Nov/2010:21:26:43] [22:Source Thread] add_chunk: hex [], read=21 [02/Nov/2010:21:26:43] [22:Source Thread] add_chunk: http chunk left=0 [02/Nov/2010:21:26:43] [22:Source Thread] DEBUG: Source received 0 bytes in try 2, total 0, errno: 0 [02/Nov/2010:21:26:43] [22:Source Thread] Didn't receive data from source after 800 milliseconds, assuming it died...

A bit debugging found that this caused by the "http chunk left=0" condition, the recv will return 0 because recv length parameter is zero (con->http_chunk->left - read_bytes =0) in source.c:663

len = recv(con->sock, con->food.source->chunk[con->food.source->cid].data + read_bytes, con->http_chunk->left - read_bytes, 0);

when len=0, subsequently maxread=0 as well. These cause the while loop to terminate on line 737 or 744. I believe this code is the same as 2.0.14.

=========== second message =================== But in my case connection is not shutdown (I can see from wireshark). Note that recv returns 0 if the length parameter is zero (which is not undocumented in the manual) and it does not return -1 in this case. I have attached a sample program to demonstrate that, to test “ telnet localhost 5000” and type some chars and a return from another terminal.

[jshih@ntriptest tcp_server]$ make tcp_recv cc tcp_recv.c -o tcp_recv [jshih@ntriptest tcp_server]$ ./tcp_recv

TCPServer Waiting for client on port 5000 got a connection from (127.0.0.1 , 43891)bytes_recieved 0 errno 0 bytes_recieved 0 errno 0 bytes_recieved 0 errno 0

I know my server is continuously sending but with inserted delay test. Further I changed the code to demonstrate that, there are data in the pipe in my case:

if (con->http_chunk->left < SOURCE_READSIZE) {

len = recv(con->sock, con->food.source->chunk[con->food.source->cid].data + read_bytes, con->http_chunk->left - read_bytes, 0); xa_debug (4, "Recv LEN1: recv left=%d read=%d len:%d errno:%d", con->http_chunk->left, read_bytes,len, errno);

if (len == 0)

{

len = recv(con->sock, con->food.source->chunk[con->food.source->cid].data + read_bytes, con->http_chunk->left - read_bytes+1, 0); xa_debug (4, "Recv LEN2: recv left=%d read=%d len:%d errno:%d", con->http_chunk->left, read_bytes,len, errno);

len = 0;

}

maxread = (int)(0.5 * con->http_chunk->left);

Below is the log capture:

[03/Nov/2010:15:53:08] [6:Source Thread] add_chunk: hex [], read=21

[03/Nov/2010:15:53:08] [6:Source Thread] add_chunk: http chunk left=0 [03/Nov/2010:15:53:08] [6:Source Thread] Recv LEN1: recv left=0 read=0 len:0 errno:0 [03/Nov/2010:15:53:08] [6:Source Thread] Recv LEN2: recv left=0 read=0 len:1 errno:0

As you can see if I immediately give a length parameter=1, I successfully recv’ed 1 byte. So there are data.

Also I made a change to source.c (see attached). I run for hours without connection drop (previously was dropping every a few minutes), please review the changes to see if this is a right solution.

changes in source.c =

736c736 < } else if (len == 0) { ---

} else if (len == 0 && con->http_chunk->left) {

744c744 < } while ((read_bytes < maxread) && (tries < source_read_tries)); ---

} while ((con->http_chunk->left==0

read_bytes < maxread) && (tries < source_read_tries));

======================

Hi there! I have a Topcon receiver connected to a serial port of my computer with output redirected to a TCP/IP port. The receiver is configured to output GPS and GLONASS navigation messages (RTCM messages 1019 and 1020). I am trying to do PPP with BNC (v 2.5), using this stream and CLK31 or CLK11 corrections. It does not seem to work, apparently observations from the receiver arrive OK, but not ephemerides. I have validated the TCP/IP stream with other software (RTKLIB) and it works correctly for RTK. Maybe I am doing something wrong in BNC, does BNC support ephemerides coming with the obs stream, or do I have to add another stream like RTCM3EPH? Thanks for your help - Ricardo.

This may be related to issue #6. This is found in ntripcaster 2.0.15.

• It does not happen all the but can be reproduced quite frequently.
• It happens immediately after authentication, and the server send the first couple of packets.
• Can be reproduced by connecting the server to caster for 20 secs, then disconnect for 10 secs and then repeat.

Below is from my log file: [27/May/2011:21:28:38] [66576:Connection Handler] DEBUG: Building request out of [POST /jshih HTTP/1.1] [27/May/2011:21:28:38] [66576:Connection Handler] DEBUG: Building request from jshih [27/May/2011:21:28:38] [66576:Connection Handler] DEBUG: req->path = jshih, req->port = 80, protocol = 3 [27/May/2011:21:28:38] [66576:Connection Handler] get_ntrip_method: name POST [27/May/2011:21:28:38] [66576:Connection Handler] get_ntrip_method: found method [POST] [27/May/2011:21:28:38] [66576:Connection Handler] DEBUG: Adding varpair [Host] == [hera.novatel.ca] [27/May/2011:21:28:38] [66576:Connection Handler] DEBUG: Adding varpair [Ntrip-Version] == [Ntrip/2.0] [27/May/2011:21:28:38] [66576:Connection Handler] DEBUG: Adding varpair [User-Agent] == [Ntrip NovAtelServer/1.0] [27/May/2011:21:28:38] [66576:Connection Handler] DEBUG: Adding varpair [Transfer-Encoding] == [chunked] [27/May/2011:21:28:38] [66576:Connection Handler] DEBUG: Adding varpair [Connection] == [close] [27/May/2011:21:28:38] [66576:Connection Handler] DEBUG: Adding varpair [Authorization] == [Basic anNoaWg6anNoaWg=] [27/May/2011:21:28:38] [66576:Connection Handler] read header: Ntripversion 2.0 Cseq -1 Session -1 Transferencoding chunked

[27/May/2011:21:28:38] [66576:Connection Handler] DEBUG: HTTP Encoder logging in with path jshih [27/May/2011:21:28:38] [66576:Connection Handler] DEBUG: authenticate_source_request(): NTRIP2.0: checking source user [27/May/2011:21:28:38] [66576:Connection Handler] DEBUG: con_get_user() decoding: [anNoaWg6anNoaWg=] [27/May/2011:21:28:38] [66576:Connection Handler] DEBUG: con_get_user() decoded: [jshih:jshih] [27/May/2011:21:28:38] [66576:Connection Handler] DEBUG: Checking need for authentication on mount /jshih [27/May/2011:21:28:38] [66576:Connection Handler] ntrip_write_message: OK: connection 66570 from [10.4.44.132] written: [HTTP/1.1 200 OK Ntrip-Version: Ntrip/2.0 Server: NTRIP Caster/2.0.15 Date: Fri, 27 May 2011 21:28:38 GMT Cache-Control: no-store,no-cache,max-age=0 Pragma: no-cache Connection: close Transfer-Encoding: chunked ] [27/May/2011:21:28:38] [66576:Connection Handler] Accepted encoder on mountpoint /jshih from 10.4.44.132. 6 sources connected [27/May/2011:21:28:38] [66576:Source Thread] Setting fd 9 to nonblocking [27/May/2011:21:28:40] [66576:Source Thread] Didn't receive data from source after 1600 milliseconds, assuming it died... [27/May/2011:21:28:40] [66576:Source Thread] Kicking source 66570 [10.4.44.132] [Source died] [http source], connected for 2 seconds on mountpoint jshih, 0 bytes transfered. 5 sources connected [27/May/2011:21:28:40] [66576:Source Thread] DEBUG: Closing fd 9 [27/May/2011:21:28:40] [66576:Source Thread] DEBUG: Removing connection 66570 of type 1 [27/May/2011:21:28:40] [66576:Source Thread] Removing source 66570 (0xb7a00bc8) from sourcetree of (0x85b2820) [27/May/2011:21:28:40] [66576:Source Thread] DEBUG: Removing thread 66576 started at [main.c:807], reason: 'Thread Exited'