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
