aiccu can not route, looses route

[Joni-Pekka Kurronen]

ISP here at Finland has run out IPV4 but dose not offer IPV6 eighter,
customers are held behind NAT and changeing IPV4 address plus
at 4G Radio network they change conction between 2G - 3G - 4G
modes continously so packet's can be lost and timeing can be tricky!!!

You can not even buy netter connection by money, all thanks to
Minitry of Trafic !!! I love them.

AICCU dose not dedetect changes so it can not receive data, IPV4 network
works but it can have brakes and IP can change,... conection is lost at IPV6
to incoming direction and aiccu dose not find it.

You must restart aiccu time to time to keep connection.

Have I miss understood that aiccu should have it's internal "heart beat"
to sixxs.org,.... or should I do some extra configuration to get it work,..
I undestood that I should not change defaults.

I have:
Ubuntu 12.4 LTE
Huawei E398 whit drivers compiled from Huawei Site, Huawei orginal drivers for linux
4G network from Elisa ( it's HSPA not real 4G )

[Jeroen Massar (massar)]

> AICCU dose not dedetect changes so it can not receive data, IPV4 network
> works but it can have brakes and IP can change,... conection is lost at IPV6
> to incoming direction and aiccu dose not find it.

From this sentence I understand you claim that AICCU does not handle IPv4 address changes, it, or actually the protocols AYIYA and heartbeat fully support that. As such, if you think they do not please provide technical details.

> You must restart aiccu time to time to keep connection.

Restarting AICCU does not solve any problem. It will get you blocked from TIC when you do it too often as clearly described in a variety of places.

> Have I miss understood that aiccu should have it's internal "heart beat" to sixxs.org,

sixxs.org is a IPv6Gateway for HTTP, it is unrelated to AICCU.

You likely mean the heartbeat protocol or the AYIYA-internal heartbeat, these both happen automatically inside the protocol (unless specifically disabled).

The subject of your bug is:
> aiccu can not route, looses route

Why do you claim that it "can not route"? And which route does it "looses"?

[Joni-Pekka Kurronen (joni-kurronen)]

Technical detail is that fact operator changes IP time to time as well
there can missing pacets due operator switches radio mode of conection
between GRPS-UMTS-HSPA,....

If I do not restart aiccu connection dose not come back but if
do restart then it comes back immediately.

Software:

http://kurrola.dy.fi/mediawiki/index.php/Cluster_Kurrola#Connections
from ipv4: https://kurrola.dy.fi.ipv4.sixxs.org/mediawiki/index.php/Cluster_Kurrola#Connections

HW RADIO:
Saunalahti 4G
Huawei E398
USB 3.0

SW Basic stack:
Huawei 398 LINUX DRIVERS COMPILED
AICCU
SHOREWALL6

DNS:
dynamic DNS from dy.fi - kurrola.dy.fi
 and
stabile kurrola.allowed.org from free dns

I belive this somthing to do whit Operators way handle
incoming trafic and chage of IP4,.... sixxs IPV6 gose down
incoming direction but IPV4 works and sixxs IPV6 dose not
come back whitout reastarting aiccu,... I was planing to
to do script that pings my own site via sixxs and if not
find then restart,...

[Jeroen Massar (massar)]

> Technical detail is that fact operator changes IP time to time as well
> there can missing pacets due operator switches radio mode of conection
> between GRPS-UMTS-HSPA,....

That is not a *technical* detail, that is merely a description of the problem that you are seeing.

As stated, the AYIYA and heartbeat protocols both handle the situation of an IP address change.

> SHOREWALL6

How is this "shorewall6" configured, any connection tracking or other firewalling happening that is blocking packets?

> I belive this somthing to do whit Operators way handle
> incoming trafic and chage of IP4,....

If your operator intentionally (or not) is blocking AYIYA/heartbeat (you don't specify what you are using), then there is nothing that AICCU or the AYIYA/heartbeat protocols can do about this as they are not circumvention protocols.

> sixxs IPV6 gose down
> incoming direction but IPV4 works and sixxs IPV6 dose not
> come back whitout reastarting aiccu,... I was planing to
> to do script that pings my own site via sixxs and if not
> find then restart,...

From the README and also mentioned on www.sixxs.net/tools/aiccu/
------------------------
Notes
Please read the README that is included with AICCU. Following is an important section of that text:

WARNING: Never run AICCU from DaemonTools or a similar automated 'restart' tool/script. When AICCU does not start, it has a reason not to start which it gives on either the stdout or in the (sys)log file. The TIC server *will* automatically disable accounts which are detected to run in this mode. Use 'verbose true' to see more information which is especially handy when starting fails.
Please also heed the notice in the TIC FAQ which explains what happens to clients that connect repeatively.
-------------------------

Thus in case you did not bother reading that or:
 https://www.sixxs.net/news/2013/#tichammeringcontinuespleasecon-0722

now you are pointed to it. Thus be forewarned.

Thus instead of going the "Something is broken, I don't know what, I'll just restart it" route, instead please actually provide *TECHNICAL DETAILS* of the problem (strace, netstat, tcpdump, interface and routing tables etc etc etc) without that there is little anyone can say about your situation.

[Joni-Pekka Kurronen (joni-kurronen)]

If operator could block AYIA I belive aiccu did not start !

Restarting is not due aiccu is down or not running,...
.... reason or another it hangs ,... sudo restart aiccu
start's incoming ipv6 trafic,.... ping6 send's packages
while aiccu/tunnel is hangig but no response nor error!!!

So IPV4 is workin both directions,...

ANY IDEAS HOW TO TEST THAT OPERATOR IS NOT
DISTURBIN AYIA / AICCU ???

joni@mpi2:~$ sudo cat /etc/aiccu.conf
Password:
# Under control from debconf, please use 'dpkg-reconfigure aiccu' to reconfigure
# AICCU Configuration

# Login information (defaults: none)
username XXXXX
password XXXXXX

# Protocol and server to use for setting up the tunnel (defaults: none)
protocol tic
server tic.sixxs.net

# Interface names to use (default: aiccu)
# ipv6_interface is the name of the interface that will be used as a tunnel interface.
# On *BSD the ipv6_interface should be set to gifX (eg gif0) for proto-41 tunnels
# or tunX (eg tun0) for AYIYA tunnels.
ipv6_interface sixxs

# The tunnel_id to use (default: none)
# (only required when there are multiple tunnels in the list)
tunnel_id T130726

# Be verbose? (default: false)
verbose false

# Daemonize? (default: true)
# Set to false if you want to see any output
# When true output goes to syslog
#
# WARNING: never run AICCU from DaemonTools or a similar automated
# 'restart' tool/script. When AICCU does not start, it has a reason
# not to start which it gives on either the stdout or in the (sys)log
# file. The TIC server *will* automatically disable accounts which
# are detected to run in this mode.
#
daemonize true

# Automatic Login and Tunnel activation?
automatic true

# Require TLS?
# When set to true, if TLS is not supported on the server
# the TIC transaction will fail.
# When set to false, it will try a starttls, when that is
# not supported it will continue.
# In any case if AICCU is build with TLS support it will
# try to do a 'starttls' to the TIC server to see if that
# is supported.
requiretls false

# PID File
pidfile /var/run/aiccu.pid

# Add a default route (default: true)
#defaultroute true

# Script to run after setting up the interfaces (default: none)
#setupscript /usr/local/etc/aiccu-subnets.sh

# Make heartbeats (default true)
# In general you don't want to turn this off
# Of course only applies to AYIYA and heartbeat tunnels not to static ones
makebeats true

# Don't configure anything (default: false)
#noconfigure true

# Behind NAT (default: false)
# Notify the user that a NAT-kind network is detected
behindnat true

# Local IPv4 Override (default: none)
# Overrides the IPv4 parameter received from TIC
# This allows one to configure a NAT into "DMZ" mode and then
# forwarding the proto-41 packets to an internal host.
#
# This is only needed for static proto-41 tunnels!
# AYIYA and heartbeat tunnels don't require this.
#local_ipv4_override

[Jeroen Massar (massar)]

> If operator could block AYIA I belive aiccu did not start !

Even if AYIYA is blocked (or otherwise caused to be broken), AICCU can still start.

This as AICCU fetches it's configuration using the TIC protocol, which is independent of the tunnel protocol used afterwards (proto-41, optionally with heartbeat or AYIYA).

> Restarting is not due aiccu is down or not running,...
>.... reason or another it hangs ,... sudo restart aiccu
>start's incoming ipv6 trafic,.... ping6 send's packages
>while aiccu/tunnel is hangig but no response nor error!!!

Where are the interface tables, tcpdumps and other details that would maybe show an error? See previous comment for other details that would be very useful.

> ANY IDEAS HOW TO TEST THAT OPERATOR IS NOT
> DISTURBIN AYIA / AICCU ???

Providing the requested information would be a good start.

> joni@mpi2:~$ sudo cat /etc/aiccu.conf

There is very little that one can do wrong in the AICCU config; keeping the default options and just having username/password/tunnel_id is all one needs (typically at least).

But that is a config,not the output of AICCU when it is running, not a tcpdump nor any other useful technical detail.

[Lars Düsing (lars.duesing)]

Joni-Pekka, would you please be so kind, and post the output of "sudo /usr/sbin/aiccu autotest" ?
Best would be twice: One before changed IP and one after at least 2 minutes after connection is broken.

Thanks in advance.

[Jeroen Massar (massar)]

> Joni-Pekka, would you please be so kind, and post the output of "sudo /usr/sbin/aiccu autotest" ?
> Best would be twice: One before changed IP and one after at least 2 minutes after connection is broken.

That does not do anything useful. The 'autotest' mode sets up the tunnel again and thus effectively means you re-started AICCU.

(yes, I realize, it would be better if autotest could be run without setting up and breaking down the tunnel, but that is how it is at the moment).

[Joni-Pekka Kurronen (joni-kurronen)]

Problem to supply any usefull is that it dose not happen every days and sometimes
twice !!!!

Most likely this somekind of timeing / protocol,... related problem,
there have been same kind of reports but those have been negled
or system has started to work whitout explanation.

Doing dump is not very smart until problem can reapaeted or caused
somehow,...

Yes, IPV4 work's, aiccu run's and incoming IPV6 dose not work.

There is one problem but it can be rounting realted,
I have not succeed to get intranet machines routed trough
router computer whit IPV6.

So could it still be problem whit kernel ipv6 rounting and not aiccu???
I have done all needed steps to get IPV6 work ( fowarding statement, shorewall6, dhcp6 and bind )
,.. but it works only internaly at router PC which has services useing IPV6 like posix, apache

joni

[Jeroen Massar (massar)]

> Problem to supply any usefull is that it dose not happen every days and sometimes twice !!!!

Then collect the information when the problem happens. How do you mean that the problem happens 'twice'?

> Most likely this somekind of timeing / protocol,... related problem,

Unless your local system clock drifts (your computer is NTP synced right?), what kind of timing/protocol problem do you mean?

> there have been same kind of reports but those have been negled

What 'reports' are you referring to and what do you mean with 'negled'?

> Yes, IPV4 work's, aiccu run's and incoming IPV6 dose not work.

Sounds more like a firewall problem to me in that case. Please provide actual technical details, without it little anybody can say about this.

> There is one problem but it can be rounting realted,
> I have not succeed to get intranet machines routed trough
> router computer whit IPV6.

As AICCU does not handle this kind of setup, that is out of scope for this ticket. I suggest using the SixXS Forums for asking for help, there are people there who can tell you what to look at.

> So could it still be problem whit kernel ipv6 rounting and not aiccu???

It can be anything. Without details, hard to say.

> I have done all needed steps to get IPV6 work ( fowarding statement, shorewall6, dhcp6 and bind )

Again, without details, nobody can comment on this.

[Joni-Pekka Kurronen (joni-kurronen)]

once a day, twice a day,... basically I use IPV4 from intranet so can
I can not note when it happens,...

Yes, ntps,...

I mean protocol level timeing, response time, missing packets,...

Basically aiccu should not change iptables, and shorewall dose it
only ones when it have started,...,... there is no ufw,...

It might I have to make script that tryes to detect when ita happens and dose log at
that point!

[Jeroen Massar (massar)]

> I mean protocol level timeing, response time, missing packets,...

AICCU can do little about high latency or missing packets.
As for 'timing' except for the requirement that hosts are NTP synced, there is no timing, AYIYA/proto-41 are lossless protocols, the tunneled protocols (eg TCP) will take care of retransmission.

> Basically aiccu should not change iptables

AICCU does not change iptables, why do you think it does that? Please provide details.

> and shorewall dose it only ones when it have started,...,... there is no ufw,..

Even if these components do not change, if connection tracking is involved, then that might cause problems when the connection tracking is not properly tracking the connections.

[Joni-Pekka Kurronen (joni-kurronen)]

tcpdump:
- IPÅV6 dispeared
- started tcpdump
- ping6 ipv6.google.com started

joni@mpi2:~$ sudo tcpdump -i sixxs
Password:
tcpdump: WARNING: sixxs: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on sixxs, link-type RAW (Raw IP), capture size 65535 bytes
11:09:15.369081 IP6 cl-868.hel-01.fi.sixxs.net > arn02s06-in-x10.1e100.net: ICMP6, echo request, seq 1, length 64
11:09:16.368358 IP6 cl-868.hel-01.fi.sixxs.net > arn02s06-in-x10.1e100.net: ICMP6, echo request, seq 2, length 64
11:09:16.370792 IP6 cl-868.hel-01.fi.sixxs.net.42487 > 2001:b18:0:1000:2e0:81ff:fe61:ae0d.domain: 22032+ [1au] AAAA? daisy.ubuntu.com. (45)
11:09:16.371290 IP6 cl-868.hel-01.fi.sixxs.net.38075 > 2001:b18:0:1000:2e0:81ff:fe61:ae0d.domain: 52486+ [1au] PTR? d.0.e.a.1.6.e.f.f.f.1.8.0.e.2.0.0.0.0.1.0.0.0.0.8.1.b.0.1.0.0.2.ip6.arpa. (101)
11:09:16.371479 IP6 cl-868.hel-01.fi.sixxs.net.55078 > 2001:b18:0:1000:2e0:81ff:fe61:ae0d.domain: 40347+ [1au] NS? . (28)
11:09:17.368344 IP6 cl-868.hel-01.fi.sixxs.net > arn02s06-in-x10.1e100.net: ICMP6, echo request, seq 3, length 64
11:09:18.368330 IP6 cl-868.hel-01.fi.sixxs.net > arn02s06-in-x10.1e100.net: ICMP6, echo request, seq 4, length 64
11:09:19.368343 IP6 cl-868.hel-01.fi.sixxs.net > arn02s06-in-x10.1e100.net: ICMP6, echo request, seq 5, length 64
11:09:19.452981 IP6 cl-868.hel-01.fi.sixxs.net.45441 > nlede01.sixxs.net.domain: 30733+ [1au] AAAA? daisy.ubuntu.com. (45)
11:09:19.454399 IP6 cl-868.hel-01.fi.sixxs.net.32978 > nlede01.sixxs.net.domain: 38315+ [1au] PTR? c.e.b.0.6.4.e.f.f.f.3.b.2.0.2.0.f.4.0.0.3.0.0.0.8.b.7.0.1.0.0.2.ip6.arpa. (101)
11:09:19.454537 IP6 cl-868.hel-01.fi.sixxs.net.55469 > nlede01.sixxs.net.domain: 33823+ [1au] NS? . (28)
11:09:20.368351 IP6 cl-868.hel-01.fi.sixxs.net > arn02s06-in-x10.1e100.net: ICMP6, echo request, seq 6, length 64
11:09:21.368325 IP6 cl-868.hel-01.fi.sixxs.net > arn02s06-in-x10.1e100.net: ICMP6, echo request, seq 7, length 64
11:09:22.368359 IP6 cl-868.hel-01.fi.sixxs.net > arn02s06-in-x10.1e100.net: ICMP6, echo request, seq 8, length 64
11:09:23.368360 IP6 cl-868.hel-01.fi.sixxs.net > arn02s06-in-x10.1e100.net: ICMP6, echo request, seq 9, length 64
11:09:24.368364 IP6 cl-868.hel-01.fi.sixxs.net > arn02s06-in-x10.1e100.net: ICMP6, echo request, seq 10, length 64
11:09:25.368372 IP6 cl-868.hel-01.fi.sixxs.net > arn02s06-in-x10.1e100.net: ICMP6, echo request, seq 11, length 64
11:09:26.368353 IP6 cl-868.hel-01.fi.sixxs.net > arn02s06-in-x10.1e100.net: ICMP6, echo request, seq 12, length 64
11:09:27.368369 IP6 cl-868.hel-01.fi.sixxs.net > arn02s06-in-x10.1e100.net: ICMP6, echo request, seq 13, length 64
11:09:28.368354 IP6 cl-868.hel-01.fi.sixxs.net > arn02s06-in-x10.1e100.net: ICMP6, echo request, seq 14, length 64
11:09:29.368369 IP6 cl-868.hel-01.fi.sixxs.net > arn02s06-in-x10.1e100.net: ICMP6, echo request, seq 15, length 64
11:09:30.368356 IP6 cl-868.hel-01.fi.sixxs.net > arn02s06-in-x10.1e100.net: ICMP6, echo request, seq 16, length 64
11:09:31.368415 IP6 cl-868.hel-01.fi.sixxs.net > arn02s06-in-x10.1e100.net: ICMP6, echo request, seq 17, length 64
11:09:32.368335 IP6 cl-868.hel-01.fi.sixxs.net > arn02s06-in-x10.1e100...

[Joni-Pekka Kurronen (joni-kurronen)]

So, I do not see difrence at sixxs interface after restarting aiccu, sixxs interface
repair's, resets somthing at kernel routing,... correct ???

It can be incoming packets are not coming to ping6 even PC receives,...

ping6 out put is here :

joni@mpi2:~$ ping6 ipv6.google.com
PING ipv6.google.com(arn02s06-in-x10.1e100.net) 56 data bytes
^X^C
--- ipv6.google.com ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 2999ms

joni@mpi2:~$ restart aiccu
restart: Rejected send message, 1 matched rules; type="method_call", sender=":1.1988" (uid=1000 pid=13866 comm="restart aiccu ") interface="com.ubuntu.Upstart0_6.Job" member="Restart" error name="(unset)" requested_reply="0" destination="com.ubuntu.Upstart" (uid=0 pid=1 comm="/sbin/init")
joni@mpi2:~$ sudo restart aiccu
Password:
aiccu start/running
joni@mpi2:~$ ping6 ipv6.google.com
PING ipv6.google.com(arn02s06-in-x10.1e100.net) 56 data bytes
64 bytes from arn02s06-in-x10.1e100.net: icmp_seq=1 ttl=55 time=88.4 ms
64 bytes from arn02s06-in-x10.1e100.net: icmp_seq=2 ttl=55 time=46.9 ms
64 bytes from arn02s06-in-x10.1e100.net: icmp_seq=3 ttl=55 time=55.2 ms
64 bytes from arn02s06-in-x10.1e100.net: icmp_seq=4 ttl=55 time=64.1 ms
64 bytes from arn02s06-in-x10.1e100.net: icmp_seq=5 ttl=55 time=52.1 ms
64 bytes from arn02s06-in-x10.1e100.net: icmp_seq=6 ttl=55 time=50.2 ms
64 bytes from arn02s06-in-x10.1e100.net: icmp_seq=7 ttl=55 time=49.1 ms
64 bytes from arn02s06-in-x10.1e100.net: icmp_seq=8 ttl=55 time=47.2 ms
^X^C
--- ipv6.google.com ping statistics ---
8 packets transmitted, 8 received, 0% packet loss, time 7011ms
rtt min/avg/max/mdev = 46.949/56.697/88.472/13.095 ms
joni@mpi2:~$

[Joni-Pekka Kurronen (joni-kurronen)]

I do next dump both IPV6 and IPV4 trafic if that brings more!
Any other ideas,... let's wait when IPV6 drops again.

[Jeroen Massar (massar)]

> joni@mpi2:~$ sudo tcpdump -i sixxs

Dumping the tunneling interface will only show the traffic that goes into the tunnel.

For any kind of tunneling protocol you need to look at the interface that the tunneling happens over.

Also, using hostname resolving makes it difficult to see what is really involved, use -n flag.

Note that SixXS publishes a really good list of things to report:
https://www.sixxs.net/contact/#problems

which mentions all these things. If you would actually report all the things requested there it would avoid having to file so many comments in this bug.

>So, I do not see difrence at sixxs interface after restarting aiccu, sixxs interface
> repair's, resets somthing at kernel routing,... correct ???

Can you please rewrite this sentence into separate sentences as I don't understand what you are trying to ask.

[Joni-Pekka Kurronen (joni-kurronen)]

I have looked out interface trafic tcpdum and I could not find problem.

Configuration: http://

Terminal commads while recording trafic headers:

joni@mpi2:/etc/apache2/SSL$ ping6 ipv6.google.com
PING ipv6.google.com(arn06s01-in-x12.1e100.net) 56 data bytes
^X^C
--- ipv6.google.com ping statistics ---
44 packets transmitted, 0 received, 100% packet loss, time 43344ms

joni@mpi2:/etc/apache2/SSL$ ping lut.fi
PING lut.fi (157.24.2.14) 56(84) bytes of data.
64 bytes from www.lut.fi (157.24.2.14): icmp_req=1 ttl=57 time=29.8 ms
64 bytes from www.lut.fi (157.24.2.14): icmp_req=2 ttl=57 time=28.8 ms
64 bytes from www.lut.fi (157.24.2.14): icmp_req=3 ttl=57 time=28.9 ms
64 bytes from www.lut.fi (157.24.2.14): icmp_req=4 ttl=57 time=27.8 ms
^X^C
--- lut.fi ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3001ms
rtt min/avg/max/mdev = 27.858/28.883/29.875/0.724 ms

joni@mpi2:/etc/apache2/SSL$ sudo restart aiccu
Password:
aiccu start/running

joni@mpi2:/etc/apache2/SSL$ ping6 ipv6.google.com
PING ipv6.google.com(arn06s01-in-x13.1e100.net) 56 data bytes
64 bytes from arn06s01-in-x13.1e100.net: icmp_seq=1 ttl=55 time=70.1 ms
64 bytes from arn06s01-in-x13.1e100.net: icmp_seq=2 ttl=55 time=38.1 ms
64 bytes from arn06s01-in-x13.1e100.net: icmp_seq=3 ttl=55 time=46.8 ms
64 bytes from arn06s01-in-x13.1e100.net: icmp_seq=4 ttl=55 time=45.5 ms
64 bytes from arn06s01-in-x13.1e100.net: icmp_seq=5 ttl=55 time=43.8 ms
^X^C
--- ipv6.google.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 38.165/48.899/70.102/11.006 ms
joni@mpi2:/etc/apache2/SSL$

sixxs:

11:23:08.842817 IP6 cl-868.hel-01.fi.sixxs.net > arn06s01-in-x12.1e100.net: ICMP6, echo request, seq 1, length 64
11:23:09.850798 IP6 cl-868.hel-01.fi.sixxs.net > arn06s01-in-x12.1e100.net: ICMP6, echo request, seq 2, length 64
11:23:10.858779 IP6 cl-868.hel-01.fi.sixxs.net > arn06s01-in-x12.1e100.net: ICMP6, echo request, seq 3, length 64
11:23:11.866814 IP6 cl-868.hel-01.fi.sixxs.net > arn06s01-in-x12.1e100.net: ICMP6, echo request, seq 4, length 64
11:23:12.874787 IP6 cl-868.hel-01.fi.sixxs.net > arn06s01-in-x12.1e100.net: ICMP6, echo request, seq 5, length 64
11:23:13.882830 IP6 cl-868.hel-01.fi.sixxs.net > arn06s01-in-x12.1e100.net: ICMP6, echo request, seq 6, length 64
11:23:14.890877 IP6 cl-868.hel-01.fi.sixxs.net > arn06s01-in-x12.1e100.net: ICMP6, echo request, seq 7, length 64
11:23:15.898851 IP6 cl-868.hel-01.fi.sixxs.net > arn06s01-in-x12.1e100.net: ICMP6, echo request, seq 8, length 64
11:23:16.906911 IP6 cl-868.hel-01.fi.sixxs.net > arn06s01-in-x12.1e100.net: ICMP6, echo request, seq 9, length 64
11:23:17.914885 IP6 cl-868.hel-01.fi.sixxs.net > arn06s01-in-x12.1e100.net: ICMP6, echo request, seq 10, length 64
11:23:18.922854 IP6 cl-868.hel-01.fi.sixxs.net > arn06s01-in-x12.1e100.net: ICMP6, echo request, seq 11, length 64
11:23:19.930843 IP6 cl-868.hel-01.fi.sixxs.net > arn06s01-in-x12.1e100.net: ICMP6, echo request, seq 12, length 64
11:23:20.938836 IP6 cl-868.hel-01.fi.sixxs.net > arn06s01-in-x12.1e100.net: ICMP6, echo request, seq 13, length 64
11:23:21.946775 IP6 cl-868.hel-01.fi.sixxs.net > arn06s01-in-x12...

[Joni-Pekka Kurronen (joni-kurronen)]

hi,

One reason found, that was at evneing ifconfig wlan2 down and
at morning ifconfig wlan up,... that stops trafic trough sixxs,...
This is fixed to give restart aiccu after ifconfig wlan up .

Also got new Huawei driver that gives staedy trafic to ppp0.

Still ther have been mystery stops randomly at day,... ppp0
 up down transition, could it stop aiccu working?

joni

[Jeroen Massar (massar)]

> THEN TCPDUMP STOPS WHEN GIVING RESTART AICCU DUE SIXXS DROPS OUT

What do you mean with this sentence? Can you rephrase it? (possibly with interpunction and possibly also in lowercase?)

It sounds like you are restarting things, why?

Note that, as stated on the contact page mentioned in a previous comment on this bug, looking at the tunneled interface ('sixxs' in this case) is fruitless; the underlying interface is what should be looked at as that will show the actual packets being sent out.

> ppp0 trafic tcpdump:

You might want to filter out all non-relevant traffic. Relevant traffic would be the actual AYIYA packets and any kind of ICMP, everything else just makes people need to search. If you do not want to, then provide a pcap (though limit the packet size then) so that it can be loaded into wireshark or similar, grepping text is a lot of work. (also publishing your private traffic (IMAP to yahoo, XMPP to Google etc) is likely something to be avoided).

On top of that, the '-n' option (network numbers / do not resolve) is awesome, makes things a lot more readable too.

The last lines show:

11:25:29.977623 IP fihel01.sixxs.net.5072 > 10.175.110.58.53305: UDP, length 1324
11:25:29.977849 IP 10.175.110.58.53305 > fihel01.sixxs.net.5072: UDP, length 116
11:25:29.997546 IP fihel01.sixxs.net.5072 > 10.175.110.58.53305: UDP, length 1324
11:25:29.997643 IP fihel01.sixxs.net.5072 > 10.175.110.58.53305: UDP, length 1324
11:25:29.997799 IP 10.175.110.58.53305 > fihel01.sixxs.net.5072: UDP, length 116
11:25:29.997847 IP 10.175.110.58.53305 > fihel01.sixxs.net.5072: UDP, length 116
11:25:30.007499 IP fihel01.sixxs.net.5072 > 10.175.110.58.53305: UDP, length 1324

Seems nothing wrong with that. Shows that you are sending and receiving packets back.

> One reason found, that was at evneing ifconfig wlan2 down and
> at morning ifconfig wlan up,... that stops trafic trough sixxs,...

Where are the details as requested several times already?

> This is fixed to give restart aiccu after ifconfig wlan up .

Sounds more like your machine is in such an inconsistent state that that resolves some kind of problem.

Now, the proper solution is not a restart, but providing enough details so that an answer can be found.

> Also got new Huawei driver that gives staedy trafic to ppp0.

As you did not mention Huawei before, what kind of device is this and how does it relate?

Next to that, it seems you are mixing "wlan" and "ppp0" here, which is the actual device being used for connectivity?

> Still ther have been mystery stops randomly at day,... ppp0
> up down transition, could it stop aiccu working?

Without details, little anyone can say.

[Lars Düsing (lars.duesing)]

Joni-Pekka,
in short:
would you please be so kind, and start "sudo tcpdump -i wlan0 -s 1514 -w aiccu.tcpdump tcp port 3874 or udp port 3740 or udp port 5072 or proto 41 or icmp" in one terminal and "ping6 -c5 heise.de" in an other.
After the ping6 finishes, type ctrl-c in the tcpdump-terminal to stop tcpdump.
Then send us the file aiccu.tcpdump .
(Of course you should do this in the event aiccu doesn't work)

The tcpdump matches all aiccu-related traffic (and so all data which runs via ipv6, so please do not login to any webservice or send any confidential data while running tcpdump!)

[Launchpad Janitor (janitor)]

[Expired for aiccu (Ubuntu) because there has been no activity for 60 days.]