Mumble verbindingen vallen weg

INTERNET TOEGANG
,
1

Beste community,

Ik start hier maar voor ik een helpdesk ticket open. Het volgende is aan de hand. Met wat vrienden gebruiken we Mumble voor voip, helaas sinds ik over ben naar Freedom verbreekt de verbinding regelmatig. Ik had nog een poosje 2 internet verbindingen en als ik mumble alleen over Ziggo liet lopen geen probleem, via Freedom gelijk. Nu heb ik Ziggo opgezegd, en heb ik dus idd het probleem weer.

De server waar ik normaal verbinding naar heb is gehost op een Odido glas verbinding, maar ik ben de enige die problemen heeft. Zou dus bij mij liggen. Ik heb ook andersom geprobeerd, iemand naar mijn mumble laten connecten, hij zit bij Caiway, binnen 3 minuten, 2x disconnectedā€¦

De melding die komt is: Server connection failed: Server is not responding to TCP pings.

Mumble gebruikt standaard UDP verkeer, poort: 64738

Iemand een idee waarom ik deze issues heb? Verder heb ik een super stabiele en snelle verbinding. En nogmaals, via Ziggo, geen issuesā€¦ Dus aan thuis apparatuur kan het vlg mij ook niet liggen. :slight_smile:
thanks!

Martijn

2

Zo ik het begrijp is Mumble d8 geen VoIp maar een chat/spraakverbinding applicatie die voor data transport gebruik maakt van UDP. Kijk of je de connectie over kan laten lopen.

Het connect/disconnect gedrag is sws aan applicatie om een verbinding operationeel actief te houden of die te herstellen. Mogelijk ontstaan timeouts omdat zg KeepAlive packets van de ā€œserver e/o clientā€ niet tijdig door of terugkomen.

Mogelijk is er bij Ziggo vice versa een andere routering dan met Freedom, te checken met traceroute (vanuit client en server). Kan wel degelijk aan gebruikte apparatuur (cq poort instellingen van ā€˜modemsā€™) liggen Ziggo != Freedom. Met bv een FritzBox is het noodzakelijk om inkomende poorten expliciet open te stellen.

3

Hoi,

VoIP / chat programma :slight_smile: idd. Ik heb in de software TCP geforceerd nu aangezet en maar eens kijken of het werkt.

Beide verbindingen (freedom en ziggo) zijn direct gekoppeld aan mijn Fortigate. Geen fritz ertussen dus. Ik weet wel dat het kastje van KPN voor glas nog een keer vervangen gaat worden. Tenminste daar heb ik een mail over gehad van Freedom een paar maanden geleden. Zou daarin zitten?

Iemand nog andere ideeƫn?

Martijn

4

Packet tracen, zo mogelijk E2E aan beide zijden van de connectie, inzoomen en vaststellen wie op welk moment het protocolair waar(om?) opgeeft.
Nuttig kan zijn dat voor beide ā€˜providersā€™ te reproduceren met dan zoek de verschillen.

Hiervoor zal je je mogelijk moeten verdiepen in ā€œMumbleā€ om de afspraken daarin te correleren. Bij VoIp protocol biedt bv WireShark allerlei plugins om packets qua inhoud inzichtelijk(er) te maken.

Het glaskastje is alleen maar een media omvormer en doet verder niets met de bovenliggende layers.

5

Wat een oorzaak kan zijn is het mogelijk niet lekkere auto-negotiate tussen ONT (mediaconverter kastje, doet mogelijk 1, 2,5 en 10 Gb en wil misshcien wel eens switchen?) en de achterliggende device/router, dan zou vastzetten op 1 snelheid een oplossing kunnen zijn. Maar dat zou dan ook in logfiles op het achterliggend edevice/router zichtbaar moeten zijn. Anders is zoals al aangegeven een end-to-end trace om vast te stellen wie/wat de handdoek in de ring gooit het beste (maar mogelijk wel een uitdaging vanwege een mogelijk onbekend? protocol).

1 like
6

Ok ik zal eens kijken of de firewall nu op auto staat.
Verder ga ik met de trace route aan de slag. Dank jullie wel voor meedenken.

7

heb mā€™n fortigate fixed op 1000full gezet, en mumble op force TCP, helaas nog steeds de issue.

traceroute:
2 24 ms 3 ms 4 ms lo0-3.bras0.fi001.nl.freedomnet.nl [185.93.175.232]
3 4 ms 3 ms 4 ms et-0-0-2-1001.core0.fi001.freedomnet.nl [185.93.175.223]
4 5 ms 4 ms 4 ms no-reverse-yet.fusixnetworks.net [37.139.140.242]
5 * 6 ms 3 ms br1.nikhef.nl.fusixnetworks.net [37.139.139.5]
6 3 ms 3 ms 3 ms as51088.frys-ix.net [185.1.203.179]
7 6 ms 4 ms 3 ms 18-7-244-46.a2b-internet.com [46.244.7.18]

zegt me zo niets eerlijk gezegd, ik probeer nu maar een ping naar alle hops die dat toestaan, en dan te kijken of ik iets zie wanneer de verbinding down gaatā€¦

8

als de lijn plat gaat dan zie ik een snelle stijging van de ping naar deze host:
3 4 ms 3 ms 4 ms et-0-0-2-1001.core0.fi001.freedomnet.nl [185.93.175.223]

Reply from 185.93.175.223: bytes=32 time=117ms TTL=62
Reply from 185.93.175.223: bytes=32 time=3ms TTL=62
Reply from 185.93.175.223: bytes=32 time=3ms TTL=62
Reply from 185.93.175.223: bytes=32 time=6ms TTL=62
Reply from 185.93.175.223: bytes=32 time=4ms TTL=62
Reply from 185.93.175.223: bytes=32 time=6ms TTL=62
Reply from 185.93.175.223: bytes=32 time=4ms TTL=62
Reply from 185.93.175.223: bytes=32 time=4ms TTL=62
Reply from 185.93.175.223: bytes=32 time=4ms TTL=62
Reply from 185.93.175.223: bytes=32 time=58ms TTL=62

dit lijkt een core router te zijn, vreemd dat die ping zo fluctureren, is de enige in het pad die dat doet

9

Traceroute gebruikt een ander protocol (ICMP) dan jouw UDP/TCP.

Ms heeft mumble debuglogging die wat kan duiden omtrent waarom/hoe/waar precies timeout.
En als gezegd met kennis van Mumble, packets tracen en die uitvlooien met waar anders dan normaal gaat. Kortom vaststellen in welke layer ontstaat een (keep-alive?) timeout.

Vraag; hoe is je fortigate op/met ā€˜ziggoā€™ verbonden ? Bridged/passthru/proxy ?
Bij freedom zal de eerste hop het eigen (PPPoE) IP-adres zijn, de tweede hop is dan de bras etc.etc. Mogelijk gebruikt de ziggo modem/router andere TTL/tijdswaarden, MTU/packetafmeting, TCP/UDP grootte etc.etc.

Vwb die corerouter 185.93.175.223, krijg ik ook wisselende tijden van vaak laag 1-2mS, regelmatig 40-60mS en soms > 100mS. Op ā€˜mijnā€™ core router (185.93.175.226) zijn die tijden consequent tussen 1-2mS.

10

dank je wel voor meedenken en je tips!

Modem van ziggo is ondertussen afgekoppeld, was via bridge mode aangesloten op de fortigate. Was makkelijk DHCP aan en gaan met die banaan :slight_smile:

De config voor Freedom is idd via pppoe en heb met MTU sizes gespeeld op deze verbinding ivm de overhead. Gebruikt is een voorbeeld config voor KPN icm Fortigate.

Ik heb Mumble niet gebruikt maar wel net een verbinding open gehad voor 2 uur, geen enkel probleemā€¦ het is dus niet continue maar lijkt op de drukkere momenten vooral voor te komen.

Het is ook alleen met Mumble zoā€¦ bv Discord geen enkele issuesā€¦ maar ja de andere gamers willen niet over naar Discord :wink: teveel optiesā€¦

11

ICMP gaat naar de control plane van de router, of te wel naar de general purpose CPU en de software. Dat is ā€˜ge-policedā€™ want routing protocollen zijn veel belangrijker.

ICMP krijgt heel erg weinig prioriteit. Het zegt helemaal niets over de delay van je productieverkeer want dat gaat over de forwarding plane, of te wel via de hardwareā€¦

Als je lijn ā€˜platā€™ is dan zul je helemaal niets terug krijgen op je ICMP echo request.

1 like
12

Duidelijk dank je wel!

Ik wil best mijn freedom internet verbinding opnieuw configureren om zeker te zijn dat hier de issues niet zitten. Heeft iemand een goede config voor een Fortigate?

ik heb de MTU sizes nog wat aangepast nav topic op Tweakers websiteā€¦

13

wat ik nu heb:

WAN fysieke interface:
config system interface
edit ā€œwan2ā€
set vdom ā€œrootā€
set allowaccess https ftm
set type physical
set role wan
set snmp-index 2
config ipv6
set autoconf enable
end
set speed 1000full
set mtu-override enable
set mtu 1512
next
end

ā€œinternet / vlan 6 interfaceā€

config system interface
edit ā€œinternetā€
set vdom ā€œrootā€
set mode pppoe
set allowaccess ftm
set alias ā€œFreedomā€
set device-identification enable
set estimated-upstream-bandwidth 1000000
set estimated-downstream-bandwidth 1000000
set monitor-bandwidth enable
set role wan
set snmp-index 18
config ipv6
set ip6-allowaccess ping
set dhcp6-prefix-delegation enable
config dhcp6-iapd-list
edit 5
set prefix-hint *::/48
next
end
end
set username "@internet"
set password ENC ****
set interface ā€œwan2ā€
set mtu-override enable
set mtu 1504
set vlanid 6
next
end

14

Vooropgesteld dat ik geen Fortigate bezit waarmee ik mijn onderstaande beweringen kan staven en/of testen. Ik herken ook niet alle opties maar ik zie wel een paar dingen waar ik commentaar op wil geven.

Ik zou hier geen IPv6 doen, omdat we dat alleen door de PPP-tunnel aanbieden.

Ik raad auto-negotiation sterk aan. Problemen met auto-negotiation stammen uit de 802.3u tijd (Fast Ethernet) en dat was 1997. Met de komst van Gigabit Ethernet in 1999 (802.3ab) is auto-negotiation enorm verbeterd. Het is ook een wezenlijk onderdeel van de 802.3ab standaard. Uitzetten en vervolgens handmatig instellen zul je aan beide kanten goed moeten doen.

MTU van 1512 bytes zou kunnen als 802.3q header geen onderdeel van ethernet zou zijn. Dat is meestal (eigenlijk altijd) wel het geval. Dus ik zou daar een MTU van 1508 bytes nemen, al denk ik dat 1512 bytes geen kwaad kan.

Tenzij je met een ZTE ONT op het Fiber Crew netwerk zit. Dat product kan niet meer dan 1500 bytes ethernet payload aan.

Geen idee of je gigabit hebt, dan wel gigabit via KPN. Het laatste doet in de praktijk vaak een stuk minder. Wellicht kun je spelen met deze parameters of ze weghalen.

Wellicht ten overvloede, username en password moeten ā€œietsā€ bevatten maar worden niet gebruikt. We raden sterk af om hier je echte username en password te gebruiken. Het is niet versleuteld en komt in logs te staan.

Hier vermoed ik dat dit 1500 bytes zou moeten zijn. Immers de PPPoE interface zou 1500 bytes moeten kunnen doen. Tenzij je met een ZTE ONT op het Fiber Crew netwerk zit. In dat geval zou je naar 1492 bytes moeten gaan.

Je kunt de MTU makkelijk testen door een IPv4-ping met het donā€™t fragment bit aan te sturen naar bijvoorbeeld www.freedom.nl.

FreeBSD, MacOS:

% ping -c 1 -D -s 1472 www.freedom.nl
PING www.freedom.nl (185.93.175.46): 1472 data bytes
1480 bytes from 185.93.175.46: icmp_seq=0 ttl=61 time=52.464 ms

ā€” www.freedom.nl ping statistics ā€”
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 52.464/52.464/52.464/0.000 ms

Linux:

$ ping -4 -M do -c 1 -s 1472 -n www.freedom.nl
PING (185.93.175.46) 1472(1500) bytes of data.
1480 bytes from 185.93.175.46: icmp_seq=1 ttl=61 time=10.4 ms

ā€” ping statistics ā€”
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 10.371/10.371/10.371/0.000 ms

Toch verwacht ik niet dit een MTU-probleem is. Ik denk dat je in de logs moet kijken en met de in Fortigate ingebouwde tcpdump aan de slag moet om het eea uit te vogelen.

Of gewoon een Fritz!box moet proberen om te kijken of het daar beter mee werkt.

2 likes
15

Ik weet niet of je bij Ziggo ook IPv6 had. Maar als ik deze thread zo lees:

Dan lijkt een zeg maar niet-stabiel IPv6-adres van je computer een mogelijke oorzaak.

1 like
16

zou dat zo simpel zijn :slight_smile: ik ga ook dat eens checken. dank je wel @arien !! erg top!

17

en idd, IPv6 op de netwerk kaart uitgezet van de PC en nu geen problemen meer. Nu gaan kijken hoe ik het wel werkend krijg :slight_smile:

bedankt allemaal! case closed!

18

Dit topic is 24 uur na het laatste antwoord automatisch gesloten. Nieuwe antwoorden zijn niet meer toegestaan.