Re: Connman VPN: Do not replace default route

2013-02-03 Thread Jukka Rissanen
Hi,

On 2 February 2013 15:02, Yevhen Kyriukha kirg...@gmail.com wrote:
 My VPN server already push information about routes like:
 server 10.10.10.0 255.255.255.0
 and
 push route 10.10.10.0 255.255.255.0 vpn_gateway

 If I use openvpn without connman the behavior is correct (routes are
 replaced only if I push redirect-gateway from the server).

This sounds like a bug.
Can you do following:

- start vpnd with connman-vpnd -n -d and direct the output to a file
- start test/monitor-vpn and direct the output to a file
- connect to your vpn (you should see server pushed routes in debug
output and also in monitor output)
- after successful connection run test/vpn-get to see if we are really
missing the ServerRoutes


Cheers,
Jukka
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman


Re: Connman VPN: Do not replace default route

2013-02-03 Thread Yevhen Kyriukha
2013/2/3 Jukka Rissanen jukka.rissa...@gmail.com:
 Hi,

 On 2 February 2013 15:02, Yevhen Kyriukha kirg...@gmail.com wrote:
 My VPN server already push information about routes like:
 server 10.10.10.0 255.255.255.0
 and
 push route 10.10.10.0 255.255.255.0 vpn_gateway

 If I use openvpn without connman the behavior is correct (routes are
 replaced only if I push redirect-gateway from the server).

 This sounds like a bug.
 Can you do following:

 - start vpnd with connman-vpnd -n -d and direct the output to a file
 - start test/monitor-vpn and direct the output to a file
 - connect to your vpn (you should see server pushed routes in debug
 output and also in monitor output)
 - after successful connection run test/vpn-get to see if we are really
 missing the ServerRoutes


 Cheers,
 Jukka

Ok, I did these steps and here's what I got:

When I run connman-vpnd -n -d program closes immediately (you can
find output in connman-vpn.log file that is attached). Is it
correct? Seems that system activates connman-vpnd by dbus.

In output of 'monitor-vpn' I see the following line:
ServerRoutes = [[{ ProtocolFamily=4 Netmask=255.255.255.0
Network=10.10.10.0 Gateway=10.10.10.81 }][{ ProtocolFamily=4
Netmask=255.255.255.0 Network=10.10.10.0 Gateway=10.10.10.81 }]]

And output of 'vpn-get' contains following:
ServerRoutes = [[{ ProtocolFamily=4 Netmask=255.255.255.0
Network=10.10.10.0 Gateway=10.10.10.81 }][{ ProtocolFamily=4
Netmask=255.255.255.0 Network=10.10.10.0 Gateway=10.10.10.81 }]]

But 'route -n' gives me the same picture that I was talking before
(vpn is a default route iface).


connman-vpn.log
Description: Binary data
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman

Re: DNS caching probably not working in dnsproxy.

2013-02-03 Thread Sameer Naik
Please ignore this.


On Fri, Feb 1, 2013 at 6:38 PM, Sameer Naik 
sameer.subscripti...@damagehead.com wrote:

 Hi,

 I am testing connman-1.10 and i get the following warnings when i try to
 resolve a dns address.

  START OF LOG
 connmand[2815]: src/dnsproxy.c:udp_listener_event() Received 32 bytes (id
 0x090c)
 connmand[2815]: src/dnsproxy.c:parse_request() id 0x090c qr 0 opcode 0
 qdcount 1 arcount 0
 connmand[2815]: src/dnsproxy.c:parse_request() query www.google.com.
 connmand[2815]: src/dnsproxy.c:resolv() server 192.168.1.1 enabled 1

 GLib-CRITICAL **: g_hash_table_lookup: assertion `hash_table != NULL'
 failed
 connmand[2815]: src/dnsproxy.c:forward_dns_reply() Received 196 bytes (id
 0x1629)
 connmand[2815]: src/dnsproxy.c:forward_dns_reply() req 0x4daba8 dstid
 0x1629 altid 0xe285 rcode 0
 connmand[2815]: src/dnsproxy.c:cache_update() offset 0 hdr 0x7fa9fb68 msg
 0x7fa9fb68 rcode 0
 connmand[2815]: src/dnsproxy.c:parse_response() qr 1 qdcount 1

 GLib-CRITICAL **: g_hash_table_lookup: assertion `hash_table != NULL'
 failed

 GLib-CRITICAL **: g_hash_table_insert_internal: assertion `hash_table !=
 NULL' failed
 connmand[2815]: src/dnsproxy.c:cache_update() cache 5 new question
 wwwgooglecom type 28 ttl 293 size 125 packet 62 dns len 62
 connmand[2815]: src/dnsproxy.c:forward_dns_reply() proto 17 sent 196 bytes
 to 9
 connmand[2815]: src/dnsproxy.c:udp_listener_event() Received 32 bytes (id
 0x9f96)
 connmand[2815]: src/dnsproxy.c:parse_request() id 0x9f96 qr 0 opcode 0
 qdcount 1 arcount 0
 connmand[2815]: src/dnsproxy.c:parse_request() query www.google.com.
 connmand[2815]: src/dnsproxy.c:resolv() server 192.168.1.1 enabled 1

 GLib-CRITICAL **: g_hash_table_lookup: assertion `hash_table != NULL'
 failed
 connmand[2815]: src/dnsproxy.c:forward_dns_reply() Received 248 bytes (id
 0x6ebe)
 connmand[2815]: src/dnsproxy.c:forward_dns_reply() req 0x4daba8 dstid
 0x6ebe altid 0x5fc0 rcode 0
 connmand[2815]: src/dnsproxy.c:cache_update() offset 0 hdr 0x7fa9fb68 msg
 0x7fa9fb68 rcode 0
 connmand[2815]: src/dnsproxy.c:parse_response() qr 1 qdcount 1

 GLib-CRITICAL **: g_hash_table_lookup: assertion `hash_table != NULL'
 failed

 GLib-CRITICAL **: g_hash_table_insert_internal: assertion `hash_table !=
 NULL' failed
 connmand[2815]: src/dnsproxy.c:cache_update() cache 6 new question
 wwwgooglecom type 1 ttl 293 size 177 packet 114 dns len 114
 connmand[2815]: src/dnsproxy.c:forward_dns_reply() proto 17 sent 248 bytes
 to 9
  END OF LOG

 It looks like there is some problem in DNS caching. Maybe the cache
 GHashTable is not initialized.
 Earlier i had glib assertion checks disabled due to which connman ended by
 crashing.

 Regards
 ~Sameer

___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman