Echo tests on ekiga

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Echo tests on ekiga

ael-3
I am trying to understand properly how to navigate firewalls using
ekiga. I have read the wiki and even contributed to it in the past.

Just now I using wireshark to compare a failed echo test (ekiga.net's own
on 500) and the ideal sip successful echo test when sent via ekiga net.

ekiga is set to use udp_port_range (on this machine) of 5081:5089 and
the firewall forwards those ports & 5080 to this machine.  The sip
listen_port is 5080.  ATM I am testing audio only, so although
tcp_port_range is set to 30000:30010, the firewall is *not* forwarding
those ports.

I attach the two simple (wide) text flow recordings from wireshark
of the successful and failed calls. Wireshark does not decode the
udp audio packets in the successful call, so that is not shown.

In the failed call to [hidden email], the first INVITE goes out,
and ekiga.net replies with the 407 Authentication request.
ekiga responds with the ACK and the modified INVITE, but ekiga.net
never responds (or is blocked by the firewall) thereafter.

Is this enough for an expert to explain what is happening?

I can of course post a -d4 log etc. if more information is needed, but I
wanted to keep this initial post simple and short.

Thanks in advance for any enlightenment.

ael


_______________________________________________
ekiga-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/ekiga-list

flow_failed_500.txt (1K) Download Attachment
flow_success_echo.txt (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Echo tests on ekiga

Damien Sandras
Le lundi 23 février 2015 à 14:35 +0000, ael a écrit :
I am trying to understand properly how to navigate firewalls using
ekiga. I have read the wiki and even contributed to it in the past.

Just now I using wireshark to compare a failed echo test (ekiga.net's own
on 500) and the ideal sip successful echo test when sent via ekiga net.

ekiga is set to use udp_port_range (on this machine) of 5081:5089 and
the firewall forwards those ports & 5080 to this machine.  The sip
listen_port is 5080.  ATM I am testing audio only, so although
tcp_port_range is set to 30000:30010, the firewall is *not* forwarding
those ports.

I attach the two simple (wide) text flow recordings from wireshark
of the successful and failed calls. Wireshark does not decode the
udp audio packets in the successful call, so that is not shown.

In the failed call to [hidden email], the first INVITE goes out,
and ekiga.net replies with the 407 Authentication request.
ekiga responds with the ACK and the modified INVITE, but ekiga.net
never responds (or is blocked by the firewall) thereafter.

Is this enough for an expert to explain what is happening?

I can of course post a -d4 log etc. if more information is needed, but I
wanted to keep this initial post simple and short.

Thanks in advance for any enlightenment.

My suspicion would be that too many audio codecs are enabled and you reach the MTU once the authentication information
has been added : the packet never reaches ekiga.net.

Can you try removing some codecs ?
--
Damien SANDRAS

Ekiga Project
http://www.ekiga.org

_______________________________________________
ekiga-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/ekiga-list
Reply | Threaded
Open this post in threaded view
|

Re: Echo tests on ekiga

ael-3
On Mon, Feb 23, 2015 at 03:43:43PM +0100, Damien Sandras wrote:

> Le lundi 23 février 2015 à 14:35 +0000, ael a écrit :
>
> > I am trying to understand properly how to navigate firewalls using
> > ekiga. I have read the wiki and even contributed to it in the past.
> >
> > I attach the two simple (wide) text flow recordings from wireshark
> > of the successful and failed calls. Wireshark does not decode the
> > udp audio packets in the successful call, so that is not shown.
> >
> > In the failed call to [hidden email], the first INVITE goes out,
> > and ekiga.net replies with the 407 Authentication request.
> > ekiga responds with the ACK and the modified INVITE, but ekiga.net
> > never responds (or is blocked by the firewall) thereafter.
>
>
> My suspicion would be that too many audio codecs are enabled and you
> reach the MTU once the authentication information
> has been added : the packet never reaches ekiga.net.
>
> Can you try removing some codecs ?

Yes. I found that all 7 of the video codecs were enabled! I hadn't
thought of looking there because I was just testing audio.

Seems a bit wrong headed that my distribution (debian for now) ship
by default a configuration that can't connect to the standard echo test.

Thanks very much. I should have thought of that myself...

ael

_______________________________________________
ekiga-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/ekiga-list
Reply | Threaded
Open this post in threaded view
|

Re: Echo tests on ekiga

Eugen Dedu-2
On 23/02/15 18:21, ael wrote:
> Yes. I found that all 7 of the video codecs were enabled! I hadn't
> thought of looking there because I was just testing audio.
>
> Seems a bit wrong headed that my distribution (debian for now) ship
> by default a configuration that can't connect to the standard echo test.

Have you just upgraded ekiga?

--
Eugen
_______________________________________________
ekiga-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/ekiga-list
Reply | Threaded
Open this post in threaded view
|

Re: Echo tests on ekiga

ael-3
On Mon, Feb 23, 2015 at 06:38:47PM +0100, Eugen Dedu wrote:
> On 23/02/15 18:21, ael wrote:
> >Yes. I found that all 7 of the video codecs were enabled! I hadn't
> >thought of looking there because I was just testing audio.
> >
> >Seems a bit wrong headed that my distribution (debian for now) ship
> >by default a configuration that can't connect to the standard echo test.
>
> Have you just upgraded ekiga?

Don't think so: debian testing kept up to date. Looking at
/var/log/dpkg*, I see the latest update was
"2015-01-11 12:29:42 status installed ekiga:amd64 4.0.1-5"

ael

_______________________________________________
ekiga-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/ekiga-list
Reply | Threaded
Open this post in threaded view
|

Re: Echo tests on ekiga

Eugen Dedu-2
On 23/02/15 19:44, ael wrote:

> On Mon, Feb 23, 2015 at 06:38:47PM +0100, Eugen Dedu wrote:
>> On 23/02/15 18:21, ael wrote:
>>> Yes. I found that all 7 of the video codecs were enabled! I hadn't
>>> thought of looking there because I was just testing audio.
>>>
>>> Seems a bit wrong headed that my distribution (debian for now) ship
>>> by default a configuration that can't connect to the standard echo test.
>>
>> Have you just upgraded ekiga?
>
> Don't think so: debian testing kept up to date. Looking at
> /var/log/dpkg*, I see the latest update was
> "2015-01-11 12:29:42 status installed ekiga:amd64 4.0.1-5"

Well, ekiga migrated to testing on 4th november...

Anyway, I noticed that sometimes all the codecs get selected when
installing or upgrading.  I will analyse this, it is on my todo list.

(It is an ekiga problem, not a debian one.)

--
Eugen
_______________________________________________
ekiga-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/ekiga-list
Reply | Threaded
Open this post in threaded view
|

Re: Echo tests on ekiga

ael-3
On Mon, Feb 23, 2015 at 09:52:30PM +0100, Eugen Dedu wrote:
>
> Well, ekiga migrated to testing on 4th november...
>
> Anyway, I noticed that sometimes all the codecs get selected when installing
> or upgrading.  I will analyse this, it is on my todo list.
>
> (It is an ekiga problem, not a debian one.)

Ok. I guess Kilian is listening to this list, so I wasn't planning a
debian bug report.

I looked back to that original dumpcap file and indeed the problem
INVITE was 1568 long while the MTU was (of course) 1500.

I have now noticed the ICMP fragment reassembly error packets *were* passed
back through the firewall to ekiga (well the right port). Should ekiga
not have repackaged the INVITE? Or at least reported the error?

Maybe this is in the wiki: I ought to check.

ael


_______________________________________________
ekiga-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/ekiga-list