Tickets - Invalid ping requests from PoP :: SixXS - IPv6 Deployment & Tunnel Broker

Ticket ID: SIXXS #5998238
Ticket Status: Resolved

PoP: decgn01 - NetCologne Gesellschaft fur Telekommunikation mbH (Cologne)

Invalid ping requests from PoP

Shadow Hawkins on Wednesday, 30 November 2011 17:38:58

Since 14:15 CET today, the ICMPv6 echo requests the PoP is sending to my Tunnel endpoint (T80502) contain an incorrect checksum and log messages regarding that fact are filling up my logs at 30 second intervals. log excerpt:

Nov 30 14:15:06 xsserver kernel: [20237949.524004] nf_ct_icmpv6: ICMPv6 checksum failed Nov 30 14:15:06 xsserver kernel: [20237949.524004] IN= OUT= SRC=2001:4dd0:ff00:0be1:0000:0000:0000:0001 DST=2001:4dd0:ff00:0be1:0000:0000:0000:0002 LEN=1028 TC=0 HOPLIMIT=64 FLOWLBL=0 PROTO=ICMPv6 TYPE=128 CODE=0 ID=16962 SEQ=0 Nov 30 14:15:06 xsserver kernel: [20237949.524004] ICMPv6 checksum failed [2001:4dd0:ff00:0be1:0000:0000:0000:0001 > 2001:4dd0:ff00:0be1:0000:0000:0000:0002] Nov 30 14:15:36 xsserver kernel: [20237979.544080] nf_ct_icmpv6: ICMPv6 checksum failed Nov 30 14:15:36 xsserver kernel: [20237979.544085] IN= OUT= SRC=2001:4dd0:ff00:0be1:0000:0000:0000:0001 DST=2001:4dd0:ff00:0be1:0000:0000:0000:0002 LEN=1028 TC=0 HOPLIMIT=64 FLOWLBL=0 PROTO=ICMPv6 TYPE=128 CODE=0 ID=16962 SEQ=1 Nov 30 14:15:36 xsserver kernel: [20237979.544300] ICMPv6 checksum failed [2001:4dd0:ff00:0be1:0000:0000:0000:0001 > 2001:4dd0:ff00:0be1:0000:0000:0000:0002] Nov 30 14:16:06 xsserver kernel: [20238009.559088] nf_ct_icmpv6: ICMPv6 checksum failed Nov 30 14:16:06 xsserver kernel: [20238009.559088] IN= OUT= SRC=2001:4dd0:ff00:0be1:0000:0000:0000:0001 DST=2001:4dd0:ff00:0be1:0000:0000:0000:0002 LEN=1028 TC=0 HOPLIMIT=64 FLOWLBL=0 PROTO=ICMPv6 TYPE=128 CODE=0 ID=16962 SEQ=2 Nov 30 14:16:06 xsserver kernel: [20238009.559088] ICMPv6 checksum failed [2001:4dd0:ff00:0be1:0000:0000:0000:0001 > 2001:4dd0:ff00:0be1:0000:0000:0000:0002] Nov 30 14:17:36 xsserver kernel: [20238099.613115] ICMPv6 checksum failed [2001:4dd0:ff00:0be1:0000:0000:0 ...

packet dump:

xsserver:/# tcpdump -i sixxs -nvxXs0 icmp6 tcpdump: WARNING: sixxs: no IPv4 address assigned tcpdump: listening on sixxs, link-type RAW (Raw IP), capture size 65535 bytes 17:29:48.707104 ip: (hlim 64, next-header ICMPv6 (58) payload length: 988) 2001:4dd0:ff00:be1::1 > 2001:4dd0:ff00:be1::2: [bad icmp6 cksum fffe!] ICMP6, echo request, length 988, seq 11 0x0000: 6000 0000 03dc 3a40 2001 4dd0 ff00 0be1 `.....:@..M..... 0x0010: 0000 0000 0000 0001 2001 4dd0 ff00 0be1 ..........M..... 0x0020: 0000 0000 0000 0002 8000 f172 4242 000b ...........rBB.. 0x0030: 6d02 983e f6b2 0400 5468 616e 6b20 796f m..>....Thank.yo 0x0040: 7520 666f 7220 6163 7475 616c 6c79 206c u.for.actually.l 0x0050: 6f6f 6b69 6e67 2061 7420 7468 6520 7061 ooking.at.the.pa 0x0060: 636b 6574 732c 2069 6620 796f 7520 6e65 ckets,.if.you.ne 0x0070: 6564 2066 7572 7468 6572 2068 656c 7020 ed.further.help. 0x0080: 646f 6e27 7420 6865 7369 7461 7465 2074 don't.hesitate.t 0x0090: 6f20 7265 6164 2068 7474 703a 2f2f 7777 o.read.http://ww 0x00a0: 772e 7369 7878 732e 6e65 742f 636f 6e74 w.sixxs.net/cont 0x00b0: 6163 742f 2061 6e64 2070 6572 7573 6520 act/.and.peruse. 0x00c0: 7468 6520 666f 7275 6d73 210a 596f 7520 the.forums!.You. 0x00d0: 476f 7420 5069 6e67 6564 2062 7920 5369 Got.Pinged.by.Si 0x00e0: 7858 5321 0a00 596f 7520 476f 7420 5069 xXS!..You.Got.Pi 0x00f0: 6e67 6564 2062 7920 5369 7858 5321 0a00 nged.by.SixXS!.. 0x0100: 596f 7520 476f 7420 5069 6e67 6564 2062 You.Got.Pinged.b 0x0110: 7920 5369 7858 5321 0a00 596f 7520 476f y.SixXS!..You.Go 0x0120: 7420 5069 6e67 6564 2062 7920 5369 7858 t.Pinged.by.SixX 0x0130: 5321 0a00 596f 7520 476f 7420 5069 6e67 S!..You.Got.Ping 0x0140: 6564 2062 7920 5369 7858 5321 0a00 596f ed.by.SixXS!..Yo 0x0150: 7520 476f 7420 5069 6e67 6564 2062 7920 u.Got.Pinged.by. 0x0160: 5369 7858 5321 0a00 596f 7520 476f 7420 SixXS!..You.Got. 0x0170: 5069 6e67 6564 2062 7920 5369 7858 5321 Pinged.by.SixXS! 0x0180: 0a00 596f 7520 476f 7420 5069 6e67 6564 ..You.Got.Pinged 0x0190: 2062 7920 5369 7858 5321 0a00 596f 7520 .by.SixXS!..You. 0x01a0: 476f 7420 5069 6e67 6564 2062 7920 5369 Got.Pinged.by.Si 0x01b0: 7858 5321 0a00 596f 7520 476f 7420 5069 xXS!..You.Got.Pi 0x01c0: 6e67 6564 2062 7920 5369 7858 5321 0a00 nged.by.SixXS!.. 0x01d0: 596f 7520 476f 7420 5069 6e67 6564 2062 You.Got.Pinged.b 0x01e0: 7920 5369 7858 5321 0a00 596f 7520 476f y.SixXS!..You.Go 0x01f0: 7420 5069 6e67 6564 2062 7920 5369 7858 t.Pinged.by.SixX 0x0200: 5321 0a00 596f 7520 476f 7420 5069 6e67 S!..You.Got.Ping 0x0210: 6564 2062 7920 5369 7858 5321 0a00 596f ed.by.SixXS!..Yo 0x0220: 7520 476f 7420 5069 6e67 6564 2062 7920 u.Got.Pinged.by. 0x0230: 5369 7858 5321 0a00 596f 7520 476f 7420 SixXS!..You.Got. 0x0240: 5069 6e67 6564 2062 7920 5369 7858 5321 Pinged.by.SixXS! 0x0250: 0a00 596f 7520 476f 7420 5069 6e67 6564 ..You.Got.Pinged 0x0260: 2062 7920 5369 7858 5321 0a00 596f 7520 .by.SixXS!..You. 0x0270: 476f 7420 5069 6e67 6564 2062 7920 5369 Got.Pinged.by.Si 0x0280: 7858 5321 0a00 596f 7520 476f 7420 5069 xXS!..You.Got.Pi 0x0290: 6e67 6564 2062 7920 5369 7858 5321 0a00 nged.by.SixXS!.. 0x02a0: 596f 7520 476f 7420 5069 6e67 6564 2062 You.Got.Pinged.b 0x02b0: 7920 5369 7858 5321 0a00 596f 7520 476f y.SixXS!..You.Go 0x02c0: 7420 5069 6e67 6564 2062 7920 5369 7858 t.Pinged.by.SixX 0x02d0: 5321 0a00 596f 7520 476f 7420 5069 6e67 S!..You.Got.Ping 0x02e0: 6564 2062 7920 5369 7858 5321 0a00 596f ed.by.SixXS!..Yo 0x02f0: 7520 476f 7420 5069 6e67 6564 2062 7920 u.Got.Pinged.by. 0x0300: 5369 7858 5321 0a00 596f 7520 476f 7420 SixXS!..You.Got. 0x0310: 5069 6e67 6564 2062 7920 5369 7858 5321 Pinged.by.SixXS! 0x0320: 0a00 596f 7520 476f 7420 5069 6e67 6564 ..You.Got.Pinged 0x0330: 2062 7920 5369 7858 5321 0a00 596f 7520 .by.SixXS!..You. 0x0340: 476f 7420 5069 6e67 6564 2062 7920 5369 Got.Pinged.by.Si 0x0350: 7858 5321 0a00 596f 7520 476f 7420 5069 xXS!..You.Got.Pi 0x0360: 6e67 6564 2062 7920 5369 7858 5321 0a00 nged.by.SixXS!.. 0x0370: 596f 7520 476f 7420 5069 6e67 6564 2062 You.Got.Pinged.b 0x0380: 7920 5369 7858 5321 0a00 596f 7520 476f y.SixXS!..You.Go 0x0390: 7420 5069 6e67 6564 2062 7920 5369 7858 t.Pinged.by.SixX 0x03a0: 5321 0a00 596f 7520 476f 7420 5069 6e67 S!..You.Got.Ping 0x03b0: 6564 2062 7920 5369 7858 5321 0a00 596f ed.by.SixXS!..Yo 0x03c0: 7520 476f 7420 5069 6e67 6564 2062 7920 u.Got.Pinged.by. 0x03d0: 5369 7858 5321 0a00 596f 7520 476f 7420 SixXS!..You.Got. 0x03e0: 5069 6e67 6564 2062 7920 5369 7858 5321 Pinged.by.SixXS! 0x03f0: 0a00 596f 7520 476f 7420 5069 6e67 6564 ..You.Got.Pinged 0x0400: 2062 7920 .by. ^C 1 packets captured 1 packets received by filter 0 packets dropped by kernel

State change: confirmed Locked

Jeroen Massar SixXS Staff

on Wednesday, 30 November 2011 18:13:40

The state of this ticket has been changed to confirmed

Invalid ping requests from PoP

Jeroen Massar SixXS Staff

on Wednesday, 30 November 2011 18:14:05

Something with the checksums indeed is broken, trying to resolve this, might take a bit.

State change: resolved Locked

Jeroen Massar SixXS Staff

on Wednesday, 30 November 2011 19:50:23

The state of this ticket has been changed to resolved

Invalid ping requests from PoP

Jeroen Massar SixXS Staff

on Wednesday, 30 November 2011 19:51:26

Seems checksums for larger ICMP responses are not calculated properly, we thus currently truncate those packets when originated from the PoP to a size that does work. Will find a proper fix for this later.

Invalid ping requests from PoP

Shadow Hawkins on Monday, 26 December 2011 21:46:30

I have read and followed the "Reporting Problems" section on the Contact page. I am removing these five pre-filled lines to demonstrate that I really read it. I am providing the full details as requested on the mentioned Contact page. If I do not remove this, then please ignore this message as I didn't read it anyway. ------------------------------------------------------------------------------>8 Same behaviour like described above happens actually again, as it can be seen in my dmesg: [1149334.642506] ICMPv6 checksum failed [2001:4dd0:ff00:075a:0000:0000:0000:0001 > 2001:4dd0:ff00:075a:0000:0000:0000:0002] [1169162.671016] ICMPv6 checksum failed [2001:4dd0:ff00:075a:0000:0000:0000:0001 > 2001:4dd0:ff00:075a:0000:0000:0000:0002] [1172218.146711] ICMPv6 checksum failed [2001:4dd0:ff00:075a:0000:0000:0000:0001 > 2001:4dd0:ff00:075a:0000:0000:0000:0002] [1202383.014543] ICMPv6 checksum failed [2001:4dd0:ff00:075a:0000:0000:0000:0001 > 2001:4dd0:ff00:075a:0000:0000:0000:0002] [1217075.424415] ICMPv6 checksum failed [2001:4dd0:ff00:075a:0000:0000:0000:0001 > 2001:4dd0:ff00:075a:0000:0000:0000:0002] [1243794.534360] ICMPv6 checksum failed [2001:4dd0:ff00:075a:0000:0000:0000:0001 > 2001:4dd0:ff00:075a:0000:0000:0000:0002] [1246915.015317] ICMPv6 checksum failed [2001:4dd0:ff00:075a:0000:0000:0000:0001 > 2001:4dd0:ff00:075a:0000:0000:0000:0002]

Invalid ping requests from PoP

Jeroen Massar SixXS Staff

on Tuesday, 27 December 2011 11:21:46

We are seeing a large amount of AYIYA hash failures from your host: Hash Fail : 3012558, last: 2011-12-27 10:14:19 (1324980859; 0 days 00:00:11 ago) If there is anything wrong, it is on your side of the link.

Invalid ping requests from PoP

Shadow Hawkins on Wednesday, 28 December 2011 00:31:53

hrm, this sounds very strange, ecspecially when keeping in mind, that i did not change anything on the host on which the tunnel endpoint at my side is (debian squeeze, atom based system; 32bit). so, by not really finding out where the problem exactly hides: do anyone of you know, what might ayiya errors in gerneral - and hashfails in special - be caused by ??? i think this also might help others fixing their problems, right? i'd be thankful in advance for any help relying to this topic.

Invalid ping requests from PoP

Jeroen Massar SixXS Staff

on Wednesday, 28 December 2011 10:25:19

Somewhere on the path between the PoP and you and vice versa packets are being corrupted.

Invalid ping requests from PoP

Shadow Hawkins on Saturday, 17 March 2012 09:24:14

I am seeing this problem on my side too, and I want to add: - I am seeing the issue on all three of the hosts currently connected via SixXS tunnels (two heartbeat, one static); - These nodes are connected to two PoPs, demuc02 and deham01; - The problems started around the same time, but the hosts were not changed; - The checksum failures are always on packets originating at the PoPs; - Two hosts also have HE.net tunnels and those do not exhibit the problem; - An entry like

ICMPv6 checksum failed [2001:0a60:f000:015b:0000:0000:0000:0001 > 2001:0470:9aad:0000:0000:0000:0000:0001]

in the logs is related to connection between a host behind demuc02 and a host connected via an HE.net tunnel. This error proves that the problem exists even on the outside of the PoPs, not just between PoP and tunnel client. All in all, I am led to believe that this problem exists on the side of SixXS.

Invalid ping requests from PoP

Jeroen Massar SixXS Staff

on Saturday, 17 March 2012 09:36:51

- The problems started around the same time, but the hosts were not changed;

Around when did it start?

- The checksum failures are always on packets originating at the PoPs;

From which address to what address? What is the content?

ICMPv6 checksum failed [2001:0a60:f000:015b:0000:0000:0000:0001 > 2001:0470:9aad:0000:0000:0000:0000:0001]

As that is sourced from the PoP, but destined to a non-pop address, how exactly does that packet arrive at the location that you receive it? Also, do you have packet dumps of these? I am really surprised about this latter one, as the PoPs do not send ICMP Ping Requests (neither in IPv4 or IPv6) from the PoPs to random addresses, they only send these to the tunnel endpoint, but then the address pair would be <tunnel>::1 to <tunnel>::2, but certainly nothing else. Of course, this could be a quite a different packet than ping requests, eg a packet too big, though. I am fairly confident it has nothing to do with the original description of this ticket, as that issue has been resolved, but it might just be that something else goes wrong somewhere of course, but in that case it would be very useful to have the full packet to be able what code path it might have taken.

Invalid ping requests from PoP

Shadow Hawkins on Saturday, 17 March 2012 13:15:57

For me, it seems that it is only between PoP and tunnel endpoint, both static. (as described above)

Invalid ping requests from PoP

Shadow Hawkins on Saturday, 17 March 2012 16:35:50

I'll try to get package dumps and then get back to you. Give me until next week though, at least

Invalid ping requests from PoP

Shadow Hawkins on Monday, 19 March 2012 11:50:10

http://scratch.madduck.net/__tmp__sixxs-icmpv6-checksum-error.pdf shows a captured packet with an invalid ICMPv6 checksum.

Invalid ping requests from PoP

Jeroen Massar SixXS Staff

on Monday, 19 March 2012 11:57:00

Do you have the pcap of that frame? Otherwise I'll need to do a lot of cut&pasting...

Invalid ping requests from PoP

Shadow Hawkins on Monday, 19 March 2012 14:56:31

Seeing the same checksum failures between PoP and Tunnel endpoint occasionally in my logs. All in all, this appears really sporadically, about once every hour. ICMPv6 checksum failed [2001:1620:0f00:001d:0000:0000:0000:0001 > 2001:1620:0f00:001d:0000:0000:0000:0002] http://www.gandalf.ch/dropbox/pckt429_invalid_checksum.pcap is a pcap with packet # 429 having an invalid checksum coming 2001:1620:0f00:001d:0000:0000:0000:0001 which I assume is the PoP because 2001:1620:0f00:001d:0000:0000:0000:0002 is my endpoint. Hope this helps.

Invalid ping requests from PoP

Shadow Hawkins on Monday, 19 March 2012 18:19:15

http://scratch.madduck.net/__tmp__icmpv6-checksum-errors is a Pcap file and fram 119 the one with the invalid checksum.

Invalid ping requests from PoP

Jeroen Massar SixXS Staff

on Monday, 19 March 2012 18:39:36

Thanks, I'll see if I can figure out where what goes wrong, now with two separate pcaps it should be easier to determine.

Invalid ping requests from PoP

Shadow Hawkins on Sunday, 29 April 2012 11:52:16

A pcap with six problematic packets: http://tukaani.org/temp/fihel01_icmpv6_bad_checksums.pcap.gz Packet numbers, the incorrect checksums and the correct checksums: 1977 0x94FF 0x93FF 2450 0xA7FF 0xA6FF 2615 0xD1FF 0xD0FF 2778 0xD4FF 0xD3FF 4185 0x92FF 0x91FF 4302 0xE0FF 0xDFFF All the problematic checksums have 0xFF as the low octet and have got 0x100 added to the correct value.

Invalid ping requests from PoP

Shadow Hawkins on Monday, 07 May 2012 11:57:02

Any news?

Invalid ping requests from PoP

Jeroen Massar SixXS Staff

on Monday, 07 May 2012 13:03:20

ETOOBUSY, I didn't have time yet to debug it.

Invalid ping requests from PoP

Shadow Hawkins on Friday, 24 August 2012 16:08:19

This happens to me too, PoP czprg01, tunnel via ayiya: ICMPv6 checksum failed [2a01:8c00:ff00:01ca:0000:0000:0000:0001 > 2a01:8c00:ff00:01ca:0000:0000:0000:0002]

Invalid ping requests from PoP

Shadow Hawkins on Thursday, 13 September 2012 11:39:27

One thing to check for (on both ends) is TCP checksum off-loading. When TCP checksum calculation/verification is off-loaded to the network interface, a pcap trace can seem wrong as the checksum is usually not stored in the kernel buffer. Or the hardware can be broken.. To diagnose this, try turning hardware checksum calculation off and/or swapping network interfaces.

Invalid ping requests from PoP

Jeroen Massar SixXS Staff

on Thursday, 13 September 2012 11:42:07

One thing to check for (on both ends) is TCP checksum off-loading.

It is the ICMP checksum that is wrong here. This is simply caused by a bug in sixxsd that I have not have had the time to further diagnose and fix yet as a lot of other things have been popping up and as this does not hurt (much at least, as it only happens seldomly and the only real problem it can cause is a MTU issue, which is generally not a problem as the tunnel MTU is lower already anyway), it has not been a priority either.

Invalid ping requests from PoP

Shadow Hawkins on Tuesday, 25 September 2012 23:08:52

Hello Jeroen, I'm curious about the status of the bug. No rush, just wanted to know if you had the chance to look into this. I'm asking because I've experienced similar problems: - tunnel works fine, but then suddenly stops working - ipv4 to pop endpoint works fine, ipv6 traffic is going from my end to the pop, but no return traffic - I get ICMPv6 checksum errors as well - aiccu restart doesn't solve anything, but it reports that everything is ok - I've tried rebooting my modem (I'm behind NAT), didn't solve anything - my SixXS packet loss graphs go from around 0% to 100% Tunnel ID: T62225 Extra information: I've used my tunnel with a higher MTU than usual (I believe it was 1472) and that worked fine, but I thought it might be the problem so I switched back to the default of 1280. But with the MTU of 1280 I still get the sudden drop of ipv6 connectivity. If you need more information, please let me know. TIA, Michiel PS. I'm replying here because I saw your recent reply, but opening another ticket might be a better idea. Please let me know if you prefer that.

Invalid ping requests from PoP

Jeroen Massar SixXS Staff

on Wednesday, 26 September 2012 09:20:43

Likely totally unrelated. The only real issue that this ICMP checksum calculation bug can cause is that when you try to reach one site that it sends back a PacketTooBig with a wrong checksum to the source which would cause that packet to go lost. Typically this is not a big issue (and why I have not taken the time to resolve it) as with UDP loss is expected and with TCP the packet will be resent at which point the PTB will be sent again with a different and likely correct checksum.

- tunnel works fine, but then suddenly stops working

The big question is WHAT stops working. Eg, can you reach the other end of the tunnel, or is it that you can't reach anything else. Also, you will want to check for any local changes in your environment (IP address change etc).

- ipv4 to pop endpoint works fine, ipv6 traffic is going from my end to the pop, but no return traffic

Could be a lot of things: packets being dropped somewhere or hash for AYIYA being wrong or heartbeat packets not arriving etc.

- I get ICMPv6 checksum errors as well

For all packets or just a few?

- aiccu restart doesn't solve anything, but it reports that everything is ok

AICCU does not report 'ok', it just configures things.

- I've tried rebooting my modem (I'm behind NAT), didn't solve anything

If you are behind a NAT all kinds of weird things can happen of course, best thing to do is to tcpdump. Also, you will want to detail how you have configured the NAT etc (eg DMZ mode etc)

Tunnel ID: T62225

You have a heartbeat tunnel. This generally means that your NAT mapping is lost on the modem as they typically do not properly forward protocol 41. Convert it to an AYIYA tunnel and all should work fine.

Invalid ping requests from PoP

Shadow Hawkins on Wednesday, 26 September 2012 12:02:54

Ok, sounds like the ICMP is not related. Apologies. Just to answer your question, I don't get the errors for all packets, it's only a couple of entries in my kernel log that say ICMPv6 checksum error. The output of 'aiccu test' reports no errors until step 6/8: Ping the IPv6 Remote/PoP Inner Tunnel Endpoint (2001:610:600:8a0::1). Sorry, I don't have the output right now as everything works at the moment. So what stops working? Basically I get no ipv6 response from the remote tunnel endpoint. During the connectivity loss, I don't get a ping reply from the remote tunnel endpoint and also other ipv6 sites (www.kame.net, www.google.com, etc.). tcpdump only shows packets going TO the remote tunnel endpoint (on the sixxs interface, but also on eth0, over ipv4), but none come back. So pings to the remote tunnel endpoint go back and forth, but ipv6 traffic isn't. I am indeed running a heartbeat tunnel, and running behind a NAT router. However, the modem has my local IPv6 tunnel endpoint (altair) listed as default host (DMZ mode), meaning all (most) packets are forwarded to the machine altair. I've tested this by sending raw packets with protocol 41 to altair from outside. Outside machine: hping3 altair --raw -H 41 tcpdump output on altair (192.168.1.4): 13:51:26.962157 IP 198.51.100.0 > 192.168.1.4: [|ip6] 13:51:27.963619 IP 198.51.100.0 > 192.168.1.4: [|ip6] 13:51:28.962122 IP 198.51.100.0 > 192.168.1.4: [|ip6] 13:51:29.961795 IP 198.51.100.0 > 192.168.1.4: [|ip6] 13:51:30.962985 IP 198.51.100.0 > 192.168.1.4: [|ip6] 13:51:31.964121 IP 198.51.100.0 > 192.168.1.4: [|ip6] (The originating IP is censored with an RFC 5737 address) If I'm not mistaken, I don't have to convert to AYIYA (higher overhead), but please correct me if I'm wrong. I know my problem is difficult to debug (especially since I don't have a lot of output of tests during the problem), but if you have any idea on how to debug (what kind of output you need) when this occurs, I'll be happy to supply them when my problems occurs again. Anyway, thanks for your time.

Invalid ping requests from PoP

Jeroen Massar SixXS Staff

on Wednesday, 26 September 2012 18:22:35

If I'm not mistaken, I don't have to convert to AYIYA (higher overhead), but please correct me if I'm wrong.

DMZ mode in some cases works just fine, but in some modems it just randomly breaks as you have indicated. In that event AYIYA might be the way to go.

I know my problem is difficult to debug (especially since I don't have a lot of output of tests during the

problem), but if you have any idea on how to debug (what kind of output you need) when this occurs,

I'll be happy to supply them when my problems occurs again.

Likely the only way to debug this is if you are able to sit on both sides of the modem to see if the packets from your internal host make it to the outside and are there translated properly and of course the other way around to see if packets from the outside make it through your NAT. Check the new Live Tunnel Status, that might help you figure something out.

Invalid ping requests from PoP

Shadow Hawkins on Friday, 28 September 2012 21:12:13

Ok, I'll give AYIYA a try then. Right now, the tunnel was not working again, switched to AYIYA and after a while it started working. If I don't report back, it's probably ok. Thanks for the help.

Invalid ping requests from PoP

Shadow Hawkins on Sunday, 30 September 2012 10:51:14

I tried AYIYA for a while and it seems to be more stable, even with a higher MTU. I'm a bit surprised to see that the Tunnel Information graphs show a lower latancy after I switched to AYIYA, but I'm not complaining. Thanks again!

Invalid ping requests from PoP

Jeroen Massar SixXS Staff

on Sunday, 30 September 2012 11:54:24

I'm a bit surprised to see that the Tunnel Information graphs show a lower latancy after I switched to AYIYA,

This could be because of QoS in the network which de-prioritize non-TCP and non-UDP, thus inclusive of protocol-41 and thus UDP based protocols might become a bit faster. But there are a lot of other factors that might be happening too.

Please note Posting is only allowed when you are logged in.