Re: [Ekiga-list] Bug prevents VPN use
Le 01/10/13 20:17, Konrad Karl a crit: Hi, On Sun, Sep 29, 2013 at 05:53:58PM +0200, Damien Sandras wrote: What Ekiga is supposed to do, is to send one message per interface with the interface IP address as source. If your routing is well configured, then only one of the various SIP messages should reach the remote user. is this behaviour required by the SIP protocol? (I also want to restrict all ekiga traffic to one specific openvpn interface at times - direct ip call w/o registration) A short explanation will be appreciated. Not specifically required. The standard says nothing about multiple interfaces handling. It is just a question of routing after that point. You can see this as a kind of fork of SIP requests. If you have two routes to the same destination, through 2 different interfaces, it should work too, but both routes have to work both ways : ie, if you can send a SIP PDU, you should be able to receive incoming requests and responses through that route too. Damien SANDRAS Ekiga Project http://www.ekiga.org ___ ekiga-list mailing list ekiga-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Bug prevents VPN use
On Wed, Oct 02, 2013 at 09:43:33AM +0200, Damien Sandras wrote: Le 01/10/13 20:17, Konrad Karl a ?crit : Hi, On Sun, Sep 29, 2013 at 05:53:58PM +0200, Damien Sandras wrote: What Ekiga is supposed to do, is to send one message per interface with the interface IP address as source. If your routing is well configured, then only one of the various SIP messages should reach the remote user. is this behaviour required by the SIP protocol? (I also want to restrict all ekiga traffic to one specific openvpn interface at times - direct ip call w/o registration) A short explanation will be appreciated. Not specifically required. The standard says nothing about multiple interfaces handling. It is just a question of routing after that point. You can see this as a kind of fork of SIP requests. If you have two routes to the same destination, through 2 different interfaces, it should work too, but both routes have to work both ways : ie, if you can send a SIP PDU, you should be able to receive incoming requests and responses through that route too. Thanks for explanation, Damien! 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). Why not do the same with SIP? (or at least have one option for that) (confessing I am a SIP noob :-) In my case there is exactly one way to reach the destination and that is VPN. Greetings, Konrad ___ ekiga-list mailing list ekiga-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Bug prevents VPN use
Le 02/10/13 10:15, Konrad Karl a crit: Not specifically required. The standard says nothing about multiple interfaces handling. It is just a question of routing after that point. You can see this as a kind of fork of SIP requests. If you have two routes to the same destination, through 2 different interfaces, it should work too, but both routes have to work both ways : ie, if you can send a SIP PDU, you should be able to receive incoming requests and responses through that route too. Thanks for explanation, Damien! 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 One of them should work. Your mail suggests that both messages are sent using the same interface but with different source IP and ports. That's weird. The best would be that you post a -d4 output somewhere (not on the mailing list) of userB trying to reach userA so that we can determine what Ekiga is doing. Damien Damien SANDRAS Ekiga Project http://www.ekiga.org ___ ekiga-list mailing list ekiga-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Bug prevents VPN use
On Wed, 2 Oct 2013, Damien Sandras wrote: 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 One of them should work. Your mail suggests that both messages are sent using the same interface but with different source IP and ports. That's weird. How does Ekiga assure that the packet is actually sent out eth0 with eth0 source IP? By default routing and source address selection are completely decoupled and if default route is to tun0, then all packets regardless of source address will go out tun0. One has to put policy routing in place to avoid this and assure that eth0 IP packets actually go out eth0 (and then you have to have the concept of multiple default routes that might change over time that needs to influence the policy routing settings). -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ ekiga-list mailing list ekiga-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Bug prevents VPN use
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
Re: [Ekiga-list] Bug prevents VPN use
Le 02/10/13 11:56, Mikael Abrahamsson a crit: On Wed, 2 Oct 2013, Damien Sandras wrote: 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 One of them should work. Your mail suggests that both messages are sent using the same interface but with different source IP and ports. That's weird. How does Ekiga assure that the packet is actually sent out eth0 with eth0 source IP? By default routing and source address selection are completely decoupled and if default route is to tun0, then all packets regardless of source address will go out tun0. One has to put policy routing in place to avoid this and assure that eth0 IP packets actually go out eth0 (and then you have to have the concept of multiple default routes that might change over time that needs to influence the policy routing settings). You are right... If Ekiga is listening on IP-A and IP-B, then it will send one SIP packet per IP. Exact routing conditions, including interface selection, are determined by the routing configuration. Damien Damien SANDRAS Ekiga Project http://www.ekiga.org ___ ekiga-list mailing list ekiga-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-list
Re: [Ekiga-list] Using Ekiga with ALSA loopback for connection to JACK - not working
Thanks for the response. I will check ptlib and see if I can figure how to make loopback available it or hack it into Ekiga. I'm currently using Pulse and the JACK's Pulse sink/source, but this will share one connection for all Pulse apps, including Ekiga Thanks again, Hugo ___ ekiga-list mailing list ekiga-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-list
