Beantwoord

0x800CCC0F bij smtp.zigoo.nl (587_STARTTTL) bij WIFI verbinding

  • 23 december 2018
  • 32 Reacties
  • 665x Bekeken


Toon eerste bericht
Dit topic is gesloten. Staat je antwoord hier niet bij, start dan een nieuw topic.

32 Reacties

Reputatie 4
Badge +2
Nog even daar ik MTU aangehaald heb en daarbij neen zou toch niet kunnen / mogen zijn.

Ik weet niet of dit nog of weer het geval is maar Ziggo heeft hier dus wel degelijk problemen mee "gehad" !?

However, ironically on an IPv6 trial, it is the IPv4 connectivity that has a real problem! The broken MTU path advertisement by the Ziggo CPE causes issues for any non-TCP traffic which tries to determine the available link MTU.
Some summary feedback for Ziggo:

Must fix

The incorrect MTU announced in an IPv4 fragmentation-needed packet, from the DS-Lite B4 functionality in the Ziggo CPE, is a fault. This cannot work, will cause massive problems with customers, etc.


En dat kan dus o.a. voor de gekke problemen met outlook verantwoordelijk zijn indien nog of weer het geval,

Dank aan @han voor de link goed soms oude zaken eens terug te lezen. 😉

http://web.archive.org/web/20170421032046/http://blog.spakka.net/

voor het geval dat die link niet meer werkt hier nog een deel daaruit, is het bij Ziggo opgelost geweest weet ik niet zo ook niet of het later weer terug gekomen kan zijn dat MTU dingetje.
code:
Problems
I’m going to document the issues that I discovered in order of severity – the most critical ones first.
Broken DS-Lite B4 element – wrong MTU advertised
The worst problem I discovered simply breaks all forms of Path MTU discovery in IPv4.
I discovered this after trying to figure out why one of my OpenVPN tunnels kept stalling. Like most VPN software, the packets from OpenVPN are sent with the DF (Don’t Fragment) flag. (This is because fragmenting a packet containing crypto material breaks the crypto, and looks like the packets have been modified in transit (because they have been!!)). In order to determine the available MTU, it relies on Path MTU discovery – if it sends a packet that is too large to be sent unfragmented down a particular link, the router must respond with ICMP ‘fragmentation needed’ type code, and report the available link MTU, so an implementation knows to reduce the packet size for this path.
Since the Ziggo router is acting as a B4 element in DS-Lite, it has to tunnel IPv4 packets to the central CGN. Therefore, the IPv4 path has a lower MTU than the normal 1500 bytes that the IPv6 path has.
To work out how much this should be, we take the normal link MTU of 1500, and subtract the overhead of tunneling it in IPv6. Assuming no extension headers, an IPv6 header is 40 bytes. So the tunnelled IPv4 MTU should be 1460.
So, here is what happens when I try and send a 1500-byte packet:
colin@router:~$ /bin/ping -s1472 -c2 -Mdo 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 1472(1500) bytes of data.
From 192.0.0.2 icmp_seq=1 Frag needed and DF set (mtu = 1474)
From 192.168.0.10 icmp_seq=2 Frag needed and DF set (mtu = 1474)

--- 8.8.8.8 ping statistics ---
1 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1001ms
The first reply is from the B4 bridging element in the Ziggo router (192.0.0.2). This tells me to please re-send with a lower MTU. Strangely it tells me to use an MTU of 1474, rather than the 1460 calculated above. We’ll get to that in a minute.
More importantly – the second reply is from my local system, not the Ziggo router. My local system has cached this path limit, and is now directly telling my ping application to use a smaller packet size. This is good behaviour – my system already knows the packet is too big, and will continue to tell local applications this for a while.
So, now lets see what happens if I send packets with the MTU that the Ziggo router has suggested (1474):
colin@router:~$ /bin/ping -s1446 -c3 -Mdo 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 1446(1474) bytes of data.
From 192.0.0.2 icmp_seq=1 Frag needed and DF set (mtu = 1474)
From 192.0.0.2 icmp_seq=2 Frag needed and DF set (mtu = 1474)
From 192.0.0.2 icmp_seq=3 Frag needed and DF set (mtu = 1474)
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2000ms
This time, something bad is happening. I am sending packets of size 1474. Yet the Ziggo router is telling me to send packets no larger than 1474. This is broken. Also, note that this time my local system is not telling me to use smaller packets – it has cached the resulting path limit of 1474, and it can see that I am sending 1474 packets, therefore it does not intervene. Yet I still get told by the Ziggo router that I need to lower the packet size to the size I am sending already.
For the sake of experimenting, I will now reduce the packet size until the Ziggo router stops sending me these bogus MTU values – to determine the real MTU limit.
colin@router:~$ /bin/ping -s1432 -c3 -Mdo 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 1432(1460) bytes of data.
72 bytes from 8.8.8.8: icmp_req=1 ttl=49 (truncated)
72 bytes from 8.8.8.8: icmp_req=2 ttl=49 (truncated)
72 bytes from 8.8.8.8: icmp_req=3 ttl=49 (truncated)
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 10.193/12.637/14.838/1.904 ms
Oh look! The actual path limit appears to be … (drum roll)…. 1460! Exactly as we calculated it should be.
As a curiousity, I was wondering where the hell the Ziggo router was getting this weird number of 1474 from. Until I was staring at these packets using tcpdump for a while, and eventually it occurred to me. Instead of subtracting 40 bytes (IPv6 tunnel overhead) from the Layer 3 link MTU (1500 bytes), it is subtracting 40 bytes from the Layer 2 max frame size (1514 bytes).
This is a comical mistake. There is no way any application on my side can recover from this situation. It cannot work. I’m guessing its a bug in the modem firmware, as the responses are coming from 192.0.0.2, which should (although I can’t confirm) be the local side of the IPv4-in-IPv6 tunnel (see RFC6333 section 10)
The fact that my IPv4-based web browsing seems to work fine makes me guess that Ziggo are also doing MSS clamping on TCP connections (either at the local modem or at the CGN). This issue only came up because my VPN software is using UDP. It is likely that other non-TCP protocols which are handled by NATs (e.g. IPsec, ICMP, etc) will have problems here.
Ziggo, you need to fix this! It will break most VPNs!
Reputatie 4
Badge +2
Oja MTU is opgelost ( of minstens geweest) The IPv4 incorrect Path MTU advertisement is fixed. This device advertises the correct MTU (1460) voor connectbox

Zoals ik al vaker zeg met glazen bol werken is lastig gissen. sorry
Ondertussen heb ik nog enkele dingen getest;
  • De Asus router (Wifi) welke ik achter de de Ziggo modem heb staan, heb ik uitgeschakeld en vervolgens de Wifi in de Ziggo modem geactiveerd. Echter ook zonder resultaat.
  • Ik heb vervolgens een Hotmail.com account (Microsoft Exchange) toegevoegd aan Outlook, dit werkt prima ! geen problemen tijdens het verzenden van e-mail.
Resultaat:
  1. Met WiFi blijven er problemen ontstaan tijdens het verzenden van e-mail via een Ziggo account met Outlook 365 (foutcode 0x800CCC0F)
  2. Met een LAN verbinding zijn er GEEN problemen, en kan ik probleemloos e-mail verzenden.
Noot: ook nog contact gezocht met Ziggo helpdesk, de beste man gaf aan dat deze storing hem boven zijn pet ging en ik weinig kans heb dat het via de Ziggo helpdesk opgelost zou gaan worden.
Reputatie 4
Badge +2
Noot: ook nog contact gezocht met Ziggo helpdesk, de beste man gaf aan dat deze storing hem boven zijn pet ging en ik weinig kans heb dat het via de Ziggo helpdesk opgelost zou gaan worden.

Zoals de foutmelding "al zegt" contact opnemen met support server admin mail enz.
Het is een gehele route, jij ziet zelfs niets in windows eventviewer?

Wil je het persee opgelost hebben dus outlook wifi ziggomail?
Dan moet je waarschijnlijk op je strepen gaan staan en zorgen voor xx lijns support en meer info uit de Ziggo mailserver logs enz

Je kan zelf ook loggen meelezen op het lijntje verwacht ik. vooral hoe de dns en afvragen gaan zover je iets kan zien. dus zoek de verschillen.

Indien je ziggo modem firmware en aansluiting ook ipv6 heeft dan kan je nog, maar duidelijk aangeven dat het voor (tijdelijke) test is alles op ipv4 laten zetten en dan testen? Dit gaat ook als men bridge mode gaat gebruiken met eigen router enz


Ook een ander device waar je outlook op staat dus met andere wifi netwerk kaart en drivers testen.
Beste Zpiep, het probleem is opgelost.
Het bleek slechts een driver update van de WiFi adapter te zijn........ nadien kon ik mijn e-mail weer verzenden zonder problemen.
Bedankt voor het meedenken!
Reputatie 4
Badge +2
Beste Zpiep, het probleem is opgelost.
Het bleek slechts een driver update van de WiFi adapter te zijn........ nadien kon ik mijn e-mail weer verzenden zonder problemen.
Bedankt voor het meedenken!


A danke voor terugmelding zo zie je maar wat drivers kunnen doen vandaar mijn tip ook nog van hierboven netwerkadapter zelf, jammer dat we de melding error log van de mailserver hier niet hebben dan kon men ook voor andere misschien de weg wijzen.

Zal wel iets met protocol enz te doen hebben die dan of niet samen (meer) werken of te traag zijn voor Ziggomail server in die combinatie.
Het kan zelfs zijn dat een setting al dan niet door de mailaanmaken of windows / outlook update ergens niet meer paste en nu weer door driver mee hersteld is.

Zelf doe ik ook best vaak even een driver werkelijk deinstalleren bij twijfels en dan echt opnieuw. ( maar ok hier best ver gezocht omdat andere mail wel ging)