Re: DNS issue in connman

2014-06-25 Thread Jukka Rissanen 
Hi Naveen,

On pe, 2014-06-20 at 09:47 +0530, Naveen Hiregoudar wrote:
 Hi Patrick,
 
 Please find below the connman logs for the test program which is provided
 below:
 
 Error logs in case of TCP:
 ==
 06/19 18:02:42 tcp_listener_event condition 0x01 channel 0x2046488 ifdata
 0x2045c98 family 2
 06/19 18:02:42 tcp_listener_event client 16 accepted
 06/19 18:02:42 tcp_listener_event client 16 created 0x204e458
 06/19 18:02:42 tcp_listener_event client 16 sent 28 bytes but expecting 1595
 pending 1567

This looks like the TCP packet your client is sending is malformed. In
DNS TCP the first two bytes should contain the packet length, so your
client has sent 28 bytes but we are expecting 1595 bytes (as indicated
by two first bytes in the message) and eventually we timeout.


 06/19 18:02:45 client_timeout client 16 timeout pending 28 bytes
 06/19 18:02:45 client_reset client 16 closing
 
 And in case of UDP below are the logs:
 ==
 06/19 17:56:56 udp_listener_event Received 41 bytes (id 0xa52e)
 06/19 17:56:56 parse_request id 0xa52e qr 0 opcode 0 qdcount 1 arcount 0
 06/19 17:56:56 parse_request query gld.push.samsungosp.com.
 06/19 17:56:56 resolv server 192.168.1.1 enabled 1
 06/19 17:56:56 cache_enforce_validity cache timeout gldpush
 samsungospcom type A
 06/19 17:56:56 cache_check_validity cache entry missing gldpush
 samsungospcom type A
 06/19 17:56:56 udp_listener_event req 0x10dda48 dstid 0x4fe0 altid 0x22f4
 06/19 17:57:01 udp_listener_event Received 41 bytes (id 0xa52e)
 06/19 17:57:01 parse_request id 0xa52e qr 0 opcode 0 qdcount 1 arcount 0
 06/19 17:57:01 parse_request query gld.push.samsungosp.com.
 06/19 17:57:01 resolv server 192.168.1.1 enabled 1
 06/19 17:57:01 udp_listener_event req 0x10ddb88 dstid 0x673c altid 0xdd38
 06/19 17:57:01 forward_dns_reply Received 224 bytes (id 0x673c)
 06/19 17:57:01 forward_dns_reply req 0x10ddb88 dstid 0x673c altid 0xdd38
 rcode 0
 06/19 17:57:01 cache_update offset 0 hdr 0xbeacab1c msg 0xbeacab1c rcode 0
 06/19 17:57:01 parse_response qr 1 qdcount 1
 06/19 17:57:01 cache_update cache 4 new question gldpush
 samsungospcom type 1 ttl 44 size 243 packet 171 dns len 171
 06/19 17:57:01 forward_dns_reply proto 17 sent 224 bytes to 8
 06/19 17:57:01 udp_listener_event Received 41 bytes (id 0xe54a)
 06/19 17:57:01 parse_request id 0xe54a qr 0 opcode 0 qdcount 1 arcount 0
 06/19 17:57:01 parse_request query gld.push.samsungosp.com.
 06/19 17:57:01 resolv server 192.168.1.1 enabled 1
 06/19 17:57:01 ns_resolv cache hit gld.push.samsungosp.com. type A
 06/19 17:57:01 send_cached_response sk 8 id 0xe54a answers 8 ptr 0x10e6f6a
 length 169 dns 169
 06/19 17:57:26 request_timeout id 0xa52e
 06/19 18:01:17 inotify_data 
 06/19 18:01:17 inotify_data bytes read 48
 
 And here is the test program to simulate the issue:
 =
   ..
   s = socket(AF_INET , SOCK_STREAM , IPPROTO_TCP);
   dest.sin_family = AF_INET;
   dest.sin_port = htons(53);
   dest.sin_addr.s_addr = inet_addr(127.0.0.1);
   ..
   qname =(unsigned char*)buf[sizeof(struct DNS_HEADER)];
   /* This will convert www.google.com to 3www6google3com */
   ChangetoDnsNameFormat(qname , host);
   printf(\n qname=%s,qname);
 
   qinfo =(struct QUESTION*)buf[sizeof(struct DNS_HEADER) +
 (strlen((const char*)qname) + 1)]; 
   qinfo-qtype = htons(T_PTR); 
   qinfo-qclass = htons(1); //its internet (lol)
 
   if (connect(s,  (const struct sockaddr *)dest, sizeof(struct
 sockaddr_in))  0) {
   perror(connect failed);
   }
   printf(\nSending Packet...);
 
   if (send(s, (char*)buf, sizeof(struct DNS_HEADER) + (strlen((const
 char*)qname)+1) + sizeof(struct QUESTION), 0)  0) {
   perror(send failed);
   }
   printf(Done);
   printf(\nReceiving answer...);
 
   if (recv (s,(char*)buf , sizeof(buf) , 0)  0) {
   perror(recvfrom failed);
   }
 =
 
 If we change the above program to UDP, it works fine.

Yes, that would be expected if you send identical data for both UDP and
TCP i.e., UDP would work but TCP would fail (because of missing packet
length).

 
 The data itself is not processed to get the tcpdump in this case so unable
 to get any meaningful  tcpdump.
 And this is the case of first lookup which fails.
 
 Please let me know if you need any further information.
 
 Regards,
 Naveen
 


Cheers,
Jukka


___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman

[PATCH] service: cancel agent requests prior to deleting wispr context

2014-06-25 Thread Slava Monich 
Calling __connman_wispr_stop() without connman_agent_cancel() allows pending
wispr requests to complete later which results in a read/write access to the
freed memory and a subsequent crash.

Calling connman_agent_cancel() without __connman_wispr_stop() stops the wispr
sequence which renders the wispr context useless. That makes no sense either.
---
 src/service.c | 2 +-
 src/wispr.c   | 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/service.c b/src/service.c
index cbca669..1df9b57 100644
--- a/src/service.c
+++ b/src/service.c
@@ -6061,7 +6061,7 @@ int __connman_service_disconnect(struct connman_service 
*service)
service-connect_reason = CONNMAN_SERVICE_CONNECT_REASON_NONE;
service-proxy = CONNMAN_SERVICE_PROXY_METHOD_UNKNOWN;
 
-   connman_agent_cancel(service);
+   __connman_wispr_stop(service);
 
reply_pending(service, ECONNABORTED);
 
diff --git a/src/wispr.c b/src/wispr.c
index dcce93c..e5a7ddc 100644
--- a/src/wispr.c
+++ b/src/wispr.c
@@ -29,6 +29,7 @@
 #include gweb/gweb.h
 
 #include connman.h
+#include agent.h
 
 #define STATUS_URL_IPV4  http://ipv4.connman.net/online/status.html;
 #define STATUS_URL_IPV6  http://ipv6.connman.net/online/status.html;
@@ -972,6 +973,7 @@ void __connman_wispr_stop(struct connman_service *service)
if (index  0)
return;
 
+   connman_agent_cancel(service);
g_hash_table_remove(wispr_portal_list, GINT_TO_POINTER(index));
 }
 
-- 
1.8.3.2

___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman