On Wed, Oct 02, 2013 at 10:48:41AM +0200, Damien Sandras wrote: > Le 02/10/13 10:15, Konrad Karl a ?crit : > ..... > >A question still remains for me: why is this done the way it is? > >If I e.g telnet some.ip.add.ress then routing rule apply and all > >traffic will go over the vpn interface (tun0 or such). > > When you are using telnet, there is an active TCP connection between > both peers. > When you are using Ekiga, you are working connectionless, ie through > UDP. That means that userB can not use the same connection to reply > back to you. All it can do is send a SIP message to a destination IP > and port. > > If user B has two local interfaces (eth0: 192.x and tun: 10.x), when > EkigaB will send a SIP message to userA, it will send it twice > (because it can not determine how routing will work, that's the > kernel responsibility) : > - one SIP message to userA through tun0 with tun0 source IP address > to userA IP and port > - one SIP message to userA through eth0 with eth0 source IP address > to user IP and port
On Linux the ip command seems to be able to determine the outgoing network interface and also the source address being used. It seems to query the kernel routing table via netlink socket (just straced the ip command) ip route get 8.8.8.8: (google name server) 8.8.8.8 via 192.168.1.1 dev p36p1 src 192.168.1.10 (correct, p36p1 was eth0 in prior universe) and ip route get 10.100.0.30: (openvpn) 10.100.0.30 via 10.100.0.9 dev tun0 src 10.100.0.10 (correct) Naive question: why cannot Ekiga do something similar? Greetings, Konrad _______________________________________________ ekiga-list mailing list ekiga-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-list
