Ethy H. Brito writes:> > Ifconfig output looks like this: > > > > root at communiceer:~# ifconfig eth1 > > eth1 Link encap:Ethernet HWaddr b4:99:ba:a9:3e:e5 > > inet addr:x.x.x.x Bcast:x.x.x.127 Mask:255.255.255.128 > > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > > RX packets:5967421 errors:0 dropped:21425 overruns:0 frame:0 > > Did you notice this ............................^^^^^ value???Yes, I did. But I assumed (hmm) that this was caused because this server is not IPv6-enabled. See also here: http://stackoverflow.com/a/30703716/3172389> Should not be a problem since you are complaining abou TX packets, not RX, > but... > > does dmesg say anything about this?Nope, nothing at all. But what I can do is set the interface into promiscuous mode with tcpdump, then there should be no dropped packets at all, I think. I'll check to make sure. Thanks for the heads up, and thanks for thinking with me everyone! Cheers, Roel> > TX packets:6085933 errors:0 dropped:0 overruns:0 carrier:0 > > collisions:0 txqueuelen:1000 > > RX bytes:1223605260 (1.1 GiB) TX bytes:2096293903 (1.9 GiB) > > Interrupt:17 Memory:fbfe0000-fc000000 > > > > I was thinking maybe there's a problem with the transmit queue, but 1000 is > > the default value for txqueuelen and I have never needed to change it. > > > > > > I have the default queueing discipline: > > > > root at communiceer:~# tc qdisc show dev eth1 > > qdisc pfifo_fast 0: root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 > 1 > > 1 1 1 > > > > > > The output of ethtool also looks good: > > > > root at communiceer:~# ethtool eth1 > > Settings for eth1: > > Supported ports: [ TP ] > > Supported link modes: 10baseT/Half 10baseT/Full > > 100baseT/Half 100baseT/Full > > 1000baseT/Full > > Supports auto-negotiation: Yes > > Advertised link modes: 10baseT/Half 10baseT/Full > > 100baseT/Half 100baseT/Full > > 1000baseT/Full > > Advertised pause frame use: No > > Advertised auto-negotiation: Yes > > Speed: 1000Mb/s > > Duplex: Full > > Port: Twisted Pair > > PHYAD: 1 > > Transceiver: internal > > Auto-negotiation: on > > MDI-X: on > > Supports Wake-on: pumbg > > Wake-on: g > > Current message level: 0x00000007 (7) > > drv probe link > > Link detected: yes > > > > > > And the nic stats also look good: > > > > root at communiceer:~# ethtool -S eth1 > > NIC statistics: > > rx_packets: 6071960 > > tx_packets: 6189424 > > rx_bytes: 1244435132 > > tx_bytes: 2117335817 > > rx_broadcast: 293751 > > tx_broadcast: 193 > > rx_multicast: 29827 > > tx_multicast: 0 > > rx_errors: 0 > > tx_errors: 0 > > tx_dropped: 0 > > multicast: 29827 > > collisions: 0 > > rx_length_errors: 0 > > rx_over_errors: 0 > > rx_crc_errors: 0 > > rx_frame_errors: 0 > > rx_no_buffer_count: 0 > > rx_missed_errors: 0 > > tx_aborted_errors: 0 > > tx_carrier_errors: 0 > > tx_fifo_errors: 0 > > tx_heartbeat_errors: 0 > > tx_window_errors: 0 > > tx_abort_late_coll: 0 > > tx_deferred_ok: 0 > > tx_single_coll_ok: 0 > > tx_multi_coll_ok: 0 > > tx_timeout_count: 0 > > tx_restart_queue: 0 > > rx_long_length_errors: 0 > > rx_short_length_errors: 0 > > rx_align_errors: 0 > > tx_tcp_seg_good: 37559 > > tx_tcp_seg_failed: 0 > > rx_flow_control_xon: 0 > > rx_flow_control_xoff: 0 > > tx_flow_control_xon: 0 > > tx_flow_control_xoff: 0 > > rx_csum_offload_good: 3447739 > > rx_csum_offload_errors: 2 > > rx_header_split: 0 > > alloc_rx_buff_failed: 0 > > tx_smbus: 0 > > rx_smbus: 0 > > dropped_smbus: 0 > > rx_dma_failed: 0 > > tx_dma_failed: 0 > > rx_hwtstamp_cleared: 0 > > uncorr_ecc_errors: 0 > > corr_ecc_errors: 0 > > tx_hwtstamp_timeouts: 0 > > > > > > So I really don't know where to look elsewhere.. > > > > Thanks, > > > > Roel > > > > > > > > > > > > -----Original Message----- > > > From: Roel van Meer <roel at 1afa.com> > > > Date: Thu, 31 Mar 2016 14:10:48 > > > To: <dovid at telecurve.com>; Asterisk Users Mailing List - Non-Commercial > > > Discussion<asterisk-users at lists.digium.com> > > > Subject: Re: [asterisk-users] Lost outgoing SIP packets > > > > > > Dovid Bender writes: > > > > > > > The tcpdump that you are running is on the Asterisk box or via port > > > > mirroring? > > > > > > It's on the asterisk box itself. > > > > > > I've already replaced the network card - no change. > > > > > > Thanks, > > > > > > Roel > > > > > > > > > > Regards, > > > > > > > > Dovid > > > > > > > > -----Original Message----- > > > > From: Roel van Meer <roel at 1afa.com> > > > > Sender: asterisk-users-bounces at lists.digium.comDate: Thu, 31 Mar 2016 > > > > 13:34:51 > > > > To: <asterisk-users at lists.digium.com> > > > > Reply-To: Asterisk Users Mailing List - Non-Commercial Discussion > > > > <asterisk-users at lists.digium.com> > > > > Subject: [asterisk-users] Lost outgoing SIP packets > > > > > > > > Hi list! > > > > > > > > I have a problem where SIP packets sent by Asterisk do not hit the > wire, > > > and > > > > I don't know what could cause this. > > > > > > > > I'm running Asterisk 1.8.28_cert5 with full SIP debug. At the same > time, > > > I'm > > > > doing a tcpdump of the traffic on the network interface. I can see in > > > > the > > > SIP > > > > debug log that asterisk is sending packets. Most of the time, I can see > > > > those packets in the tcpdump, as you would expect. > > > > However, sometimes Asterisk sends a packet that *does not show up* in > the > > > > tcpdump. Asterisk then does several retransmits (that also don't show > up). > > > > The next packet that is not a retransmit does show up again. > > > > > > > > This causes Asterisk to log the peer it was sending packets to > temporarily > > > > as Lagged or unreachable. > > > > > > > > There is no outgoing firewall on this box. > > > > > > > > Could anyone give me some pointers where to look? > > > > > > > > If Asterisk logs "VERBOSE[13019] chan_sip.c: Reliably Transmitting > (NAT) > > > > to x.x.x.x:" you would expect to see that packet in a tcpdump trace, > > > > right? What could cause this not to be so? Are there network > statistics I > > > > could look at? Is there a counter in /proc or /sys for problems with > > > > sending packets? Anything? > > > > > > > > If more information is necessary please do let me know. > > > > > > > > Thanks a lot in advance, > > > > > > > > Roel > > > > > > > > -- > > > > _____________________________________________________________________ > > > > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > > > New to Asterisk? Join us for a live introductory webinar every Thurs: > > > > http://www.asterisk.org/hello > > > > > > > > asterisk-users mailing list > > > > To UNSUBSCRIBE or update options visit: > > > > http://lists.digium.com/mailman/listinfo/asterisk-users > > > > -- > > > > _____________________________________________________________________ > > > > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > > > New to Asterisk? Join us for a live introductory webinar every Thurs: > > > > http://www.asterisk.org/hello > > > > > > > > asterisk-users mailing list > > > > To UNSUBSCRIBE or update options visit: > > > > http://lists.digium.com/mailman/listinfo/asterisk-users > > > > -- > > _____________________________________________________________________ > > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > New to Asterisk? Join us for a live introductory webinar every Thurs: > > http://www.asterisk.org/hello > > > > asterisk-users mailing list > > To UNSUBSCRIBE or update options visit: > > http://lists.digium.com/mailman/listinfo/asterisk-users >
<!DOCTYPE html>
<html><head>
<meta charset="UTF-8">
</head><body><p>Hello !</p><p>I ask if it is
necessary to install DAHDI and LIBPRI if we want to connect our asterisk to an
operator SIP (trunk SIP).</p><p>Someone for helping
me.</p><p>thanks !!!</p><blockquote
type="cite"><p>Le 31 mars 2016 à 15:59, Roel van Meer
<roel@1afa.com> a écrit :<br><br><br>Ethy H. Brito
writes:<br></p><blockquote type="cite"><p>>
Ifconfig output looks like this:</p><blockquote
type="cite"><p>root@communiceer:~# ifconfig
eth1<br>eth1 Link encap:Ethernet HWaddr b4:99:ba:a9:3e:e5<br> inet
addr:x.x.x.x Bcast:x.x.x.127 Mask:255.255.255.128<br> UP BROADCAST RUNNING
MULTICAST MTU:1500 Metric:1<br> RX packets:5967421 errors:0 dropped:21425
overruns:0 frame:0</p></blockquote><p>Did you notice this
............................^^^^^
value???</p></blockquote><p>Yes, I did. But I assumed (hmm)
that this was caused because this server is <br>not IPv6-enabled. See also
here:
http://stackoverflow.com/a/30703716/3172389<br></p><blockquote
type="cite"><p>Should not be a problem since you are
complaining abou TX packets, not RX,<br>but...<br><br>does
dmesg say anything about this?</p></blockquote><p>Nope,
nothing at all.<br><br>But what I can do is set the interface into
promiscuous mode with tcpdump, <br>then there should be no dropped packets
at all, I think. I'll check to make
<br>sure.<br><br>Thanks for the heads up, and thanks for
thinking with me
everyone!<br><br>Cheers,<br><br>Roel<br><br><br></p><blockquote
type="cite"><p>> TX packets:6085933 errors:0 dropped:0
overruns:0 carrier:0</p><blockquote
type="cite"><p>collisions:0 txqueuelen:1000<br> RX
bytes:1223605260 (1.1 GiB) TX bytes:2096293903 (1.9 GiB)<br> Interrupt:17
Memory:fbfe0000-fc000000<br><br>I was thinking maybe there's a
problem with the transmit queue, but 1000 is<br>the default value for
txqueuelen and I have never needed to change it.<br><br><br>I
have the default queueing discipline:<br><br>root@communiceer:~# tc
qdisc show dev eth1<br>qdisc pfifo_fast 0: root refcnt 2 bands 3 priomap 1
2 2 2 1 2 0 0 1 1 1
1</p></blockquote><p>1</p><blockquote
type="cite"><p>1 1 1<br><br><br>The output
of ethtool also looks good:<br><br>root@communiceer:~# ethtool
eth1<br>Settings for eth1:<br> Supported ports: [ TP ]<br>
Supported link modes: 10baseT/Half 10baseT/Full<br> 100baseT/Half
100baseT/Full<br> 1000baseT/Full<br> Supports auto-negotiation:
Yes<br> Advertised link modes: 10baseT/Half 10baseT/Full<br>
100baseT/Half 100baseT/Full<br> 1000baseT/Full<br> Advertised pause
frame use: No<br> Advertised auto-negotiation: Yes<br> Speed:
1000Mb/s<br> Duplex: Full<br> Port: Twisted Pair<br> PHYAD:
1<br> Transceiver: internal<br> Auto-negotiation: on<br>
MDI-X: on<br> Supports Wake-on: pumbg<br> Wake-on: g<br>
Current message level: 0x00000007 (7)<br> drv probe link<br> Link
detected: yes<br><br><br>And the nic stats also look
good:<br><br>root@communiceer:~# ethtool -S eth1<br>NIC
statistics:<br> rx_packets: 6071960<br> tx_packets:
6189424<br> rx_bytes: 1244435132<br> tx_bytes: 2117335817<br>
rx_broadcast: 293751<br> tx_broadcast: 193<br> rx_multicast:
29827<br> tx_multicast: 0<br> rx_errors: 0<br> tx_errors:
0<br> tx_dropped: 0<br> multicast: 29827<br> collisions:
0<br> rx_length_errors: 0<br> rx_over_errors: 0<br>
rx_crc_errors: 0<br> rx_frame_errors: 0<br> rx_no_buffer_count:
0<br> rx_missed_errors: 0<br> tx_aborted_errors: 0<br>
tx_carrier_errors: 0<br> tx_fifo_errors: 0<br> tx_heartbeat_errors:
0<br> tx_window_errors: 0<br> tx_abort_late_coll: 0<br>
tx_deferred_ok: 0<br> tx_single_coll_ok: 0<br> tx_multi_coll_ok:
0<br> tx_timeout_count: 0<br> tx_restart_queue: 0<br>
rx_long_length_errors: 0<br> rx_short_length_errors: 0<br>
rx_align_errors: 0<br> tx_tcp_seg_good: 37559<br> tx_tcp_seg_failed:
0<br> rx_flow_control_xon: 0<br> rx_flow_control_xoff: 0<br>
tx_flow_control_xon: 0<br> tx_flow_control_xoff: 0<br>
rx_csum_offload_good: 3447739<br> rx_csum_offload_errors: 2<br>
rx_header_split: 0<br> alloc_rx_buff_failed: 0<br> tx_smbus:
0<br> rx_smbus: 0<br> dropped_smbus: 0<br> rx_dma_failed:
0<br> tx_dma_failed: 0<br> rx_hwtstamp_cleared: 0<br>
uncorr_ecc_errors: 0<br> corr_ecc_errors: 0<br>
tx_hwtstamp_timeouts: 0<br><br><br>So I really don't know
where to look
elsewhere..<br><br>Thanks,<br><br>Roel<br><br><br></p><blockquote
type="cite"><p>-----Original Message-----<br>From: Roel
van Meer <roel@1afa.com><br>Date: Thu, 31 Mar 2016
14:10:48<br>To: <dovid@telecurve.com>; Asterisk Users Mailing List -
Non-Commercial<br>Discussion<asterisk-users@lists.digium.com><br>Subject:
Re: [asterisk-users] Lost outgoing SIP packets<br><br>Dovid Bender
writes:<br></p><blockquote type="cite"><p>The
tcpdump that you are running is on the Asterisk box or via
port<br>mirroring?</p></blockquote><p>It's on the
asterisk box itself.<br><br>I've already replaced the network
card - no
change.<br><br>Thanks,<br><br>Roel<br><br></p><blockquote
type="cite"><p>Regards,<br><br>Dovid<br><br>-----Original
Message-----<br>From: Roel van Meer <roel@1afa.com><br>Sender:
asterisk-users-bounces@lists.digium.comDate: Thu, 31 Mar
2016<br>13:34:51<br>To:
<asterisk-users@lists.digium.com><br>Reply-To: Asterisk Users
Mailing List - Non-Commercial Discussion<br>
<asterisk-users@lists.digium.com><br>Subject: [asterisk-users] Lost
outgoing SIP packets<br><br>Hi list!<br><br>I have a
problem where SIP packets sent by Asterisk do not hit
the</p></blockquote><p>wire,</p><blockquote
type="cite"><p>> and<br>I don't know what could
cause this.<br><br>I'm running Asterisk 1.8.28_cert5 with full
SIP debug. At the
same</p></blockquote><p>time,</p><blockquote
type="cite"><p>> I'm<br>doing a tcpdump of the
traffic on the network interface. I can see
in<br>the</p></blockquote><p>SIP</p><blockquote
type="cite"><p>debug log that asterisk is sending packets.
Most of the time, I can see<br>those packets in the tcpdump, as you would
expect.<br>However, sometimes Asterisk sends a packet that *does not show
up* in</p></blockquote><p>the</p><blockquote
type="cite"><p>> > tcpdump. Asterisk then does several
retransmits (that also don't
show</p></blockquote><p>up).</p><blockquote
type="cite"><p>> > The next packet that is not a
retransmit does show up again.<br><br>This causes Asterisk to log
the peer it was sending packets
to</p></blockquote><p>temporarily</p><blockquote
type="cite"><p>> > as Lagged or
unreachable.<br><br>There is no outgoing firewall on this
box.<br><br>Could anyone give me some pointers where to
look?<br><br>If Asterisk logs "VERBOSE[13019] chan_sip.c:
Reliably
Transmitting</p></blockquote><p>(NAT)</p><blockquote
type="cite"><p>> > to x.x.x.x:" you would expect
to see that packet in a tcpdump trace,<br>right? What could cause this not
to be so? Are there network</p></blockquote><p>statistics
I</p><blockquote type="cite"><p>> > could look
at? Is there a counter in /proc or /sys for problems with<br>sending
packets? Anything?<br><br>If more information is necessary please do
let me know.<br><br>Thanks a lot in
advance,<br><br>Roel<br><br>--<br>_____________________________________________________________________<br>--
Bandwidth and Colocation Provided by http://www.api-digital.com --<br>New
to Asterisk? Join us for a live introductory webinar every Thurs:<br>
http://www.asterisk.org/hello<br><br>asterisk-users mailing
list<br>To UNSUBSCRIBE or update options visit:<br>
http://lists.digium.com/mailman/listinfo/asterisk-users<br>--<br>_____________________________________________________________________<br>--
Bandwidth and Colocation Provided by http://www.api-digital.com --<br>New
to Asterisk? Join us for a live introductory webinar every Thurs:<br>
http://www.asterisk.org/hello<br><br>asterisk-users mailing
list<br>To UNSUBSCRIBE or update options visit:<br>
http://lists.digium.com/mailman/listinfo/asterisk-users</p></blockquote><p>--</p></blockquote><p>_____________________________________________________________________--
Bandwidth and Colocation Provided by http://www.api-digital.com --<br>New
to Asterisk? Join us for a live introductory webinar every Thurs:<br>
http://www.asterisk.org/hello<br><br>asterisk-users mailing
list<br>To UNSUBSCRIBE or update options visit:<br>
http://lists.digium.com/mailman/listinfo/asterisk-users</p></blockquote><p>--</p></blockquote><p>_____________________________________________________________________--
Bandwidth and Colocation Provided by http://www.api-digital.com --<br>New
to Asterisk? Join us for a live introductory webinar every Thurs:<br>
http://www.asterisk.org/hello<br><br>asterisk-users mailing
list<br>To UNSUBSCRIBE or update options visit:<br>
http://lists.digium.com/mailman/listinfo/asterisk-users</p></blockquote><p><br></p><div
class="io-ox-signature"><p>Mamadou
NGOM</p><p>Ingénieur Télécommunications &
Réseaux</p><p>Mobile: 06 72 45 23 03</p><p>Skype:
Mamadou Numericap</p><p>NumeriCap – SAS au capital de 30.000,00€ -
RCS de Toulon N° 530188432 – TVA FR 485301188432 – APE6110Z - ARCEP N°13/0015.
<br>siège social : « le Galaxie C » 526 avenue Maréchal de Lattre de
Tassigny 83000 Toulon. <a
href="mailto:mail%3Afinance@numericap.com">mail:
finance@numericap.com</a><br>Centre d’exploitation : « Résidence les
Coquières » 11 avenue Joseph Fallen - 13400 Aubagne – Tel
:<a>04.42.73.88.52</a> <br></p></div></body></html>
On Thu, Mar 31, 2016 at 10:24 AM, Mamadou NGOM <ngom at numericap.com> wrote:> Hello ! > > I ask if it is necessary to install DAHDI and LIBPRI if we want to connect > our asterisk to an operator SIP (trunk SIP). > > Someone for helping me. >DAHDI and libpri have nothing to do with SIP. You don't need them for SIP. Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20160331/4ee7dcbc/attachment.html>
On Thursday 31 Mar 2016, Mamadou NGOM wrote:> Hello ! > I ask if it is necessary to install DAHDI and LIBPRI if we want to connect > our asterisk to an operator SIP (trunk SIP). Someone for helping me. > thanks !!!No. DAHDI is a library for hardware interfaces to POTS, ISDN and mobile lines. LibPRI is a library specifically for primary rate ISDN interfaces (one Primary Rate ISDN = 30 lines). If you are connecting only SIP phones to your Asterisk server, and it is talking to the outside world only via a SIP trunk, then you do not need DAHDI or LibPRI. -- AJS Note: Originating address only accepts e-mail from list! If replying off- list, change address to asterisk1list at earthshod dot co dot uk .
Roel, Just another thought bouncing around... Your ifconfig output was specific to eth1. Is there an eth0 too? Is there a chance packets are heading to that other interface when they shouldn't be? Running a second tcpdump on eth0 at the same time should at least disprove the theory quickly. Pete> On 1/04/2016, at 2:59 am, Roel van Meer <roel at 1afa.com> wrote: > > > Thanks for the heads up, and thanks for thinking with me everyone!-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20160401/c64b03e7/attachment.html>
One issue that can catch you is a packet MTU limit in your path to your SIP box lower than your standard MTU. You can check that with ping -s 1500 <host> option Cheers Duncan On 01/04/16 17:12, Pete Mundy wrote:> Roel, > > Just another thought bouncing around... Your ifconfig output was > specific to eth1. Is there an eth0 too? Is there a chance packets are > heading to that other interface when they shouldn't be? Running a > second tcpdump on eth0 at the same time should at least disprove the > theory quickly. > > Pete > >> On 1/04/2016, at 2:59 am, Roel van Meer <roel at 1afa.com >> <mailto:roel at 1afa.com>> wrote: >> >> >> Thanks for the heads up, and thanks for thinking with me everyone! > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20160401/0eef1e73/attachment.html>