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
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.
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
------------------------------
Message: 4
Date: Thu, 19 Jun 2014 15:05:16 +0300
From: Patrik Flykt <patrik.fl...@linux.intel.com>
To: connman@connman.net
Subject: Re: DNS issue in connman
Message-ID: <1403179516.30880.14.camel@pflykt-mobl1>
Content-Type: text/plain; charset="UTF-8"
Hi,
On Thu, 2014-06-19 at 11:53 +0530, Naveen Hiregoudar wrote:
> Hi All,
>
> I'm facing an issue in Connman when a client finds the 'Truncated flag'
> enabled in the DNS response and tries to resend DNS request over TCP.
>
> I've checked recent DNS commits which happened in Connman, but those
changes
> are not helping completely.
>
> Please let me know if someone has come across this kind of issue.
Please describe your problem in a bit more detail. The log output of the
failing DNS lookup would be important to have, as would the
corresponding tcpdump as the exact content of the UDP or TCP DNS packets
would be needed to debug the issue.
Is this the first lookup or a subsequent one where the result is already
cached by ConnMan? Is this really going over TCP, as that's used only if
the request does not fit into an UDP one?
Cheers,
Patrik
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 65, Issue 16
***************************************
_______________________________________________
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
