[Frage] SIP Regisration / OpenVPN ?

Schweinebraten · 26 Dez 2014

Hallo allerseits,

folgende Situation:

Fritzbox 7390, Freetz 6.20-freetz-devel-12826
An Telekomanschluss, 50 MB, VoIP (6 Nummern)

Mit Original AVM SW alles Prima.

mit Freetz und den Services dropbear, openVPN, snmp, und syslog
registrieren sich die SIP Accounts nach einem Reboot, fliegen,dann aber nach kurzer Zeit (10-30min) aus der Registrierug.
Fehleermeldung: Anmeldung der Internetrufnummer (XYZ) war nicht erfolgreich. Ursache: DNS-Fehler

Wenn ich nun das openVPN stoppe, registrieren sich die SIP nummern innerhalb von 2 minuten wieder.

Machen ich nun einen

Code:

echo disable > /proc/net/avm_pa/control

und starte das OpenVPN wieder so scheint die SIP Registrierung zu bleiben. (Langzeitest >48h noch ausstehend)

Versuche avm_pa mittels Script in rc.custom / rcexternal abzuschalten haben nicht das gewünschte Ergebis gebracht

Script

Code:

/usr/bin/logger Start_of_rc.custom
/bin/echo disable > /proc/net/avm_pa/control
/usr/bin/logger End_of_rc.custom

Auch eine Modifikation der rc.openvpn führte nicht zum gewünschen Ergebnis. (immer noch Fehler bei SIP Regisration nach kurzer Zeit.)

Wie schon in anderen Themen diskutiert kann auch ich den Impact des Abschaltens von avm_pa nicht abschätzen.

Wenn nun avm_pa aktiv ist fehlem mir auch Debugging Möglichkeiten, da die relevanten Pakete nicht vom tcpdump gesehen werden.

irgendwelche Ideeen?

MfG
Schweinebraten

Config:

Code:

FREETZ_HAVE_DOT_CONFIG=y
FREETZ_USER_LEVEL_EXPERT=y
FREETZ_SHOW_ADVANCED=y
FREETZ_SHOW_EXPERT=y
FREETZ_TYPE_7390=y
FREETZ_TYPE_LANG_DE=y
FREETZ_TYPE_FIRMWARE_06_2X=y
FREETZ_TYPE_FIRMWARE_FINAL=y
FREETZ_TYPE_LANGUAGE="de"
FREETZ_TARGET_IPV6_SUPPORT=y
FREETZ_REMOVE_AHA=y
FREETZ_REMOVE_BRANDING_otwo=y
FREETZ_REMOVE_DTRACE=y
FREETZ_REMOVE_FTPD=y
FREETZ_REMOVE_HELP=y
FREETZ_REMOVE_PRINTSERV=y
FREETZ_REMOVE_SAMBA=y
FREETZ_REMOVE_SUPPORT=y
FREETZ_REMOVE_UMTSD=y
FREETZ_REMOVE_KIDS=y
FREETZ_PATCH_FREETZMOUNT=y
FREETZ_USBSTORAGE_AUTOMOUNT=y
FREETZ_AUTOMOUNT_EXT3=y
FREETZ_ADD_ETCSERVICES=y
FREETZ_RESTORE_DEBUG_CFG_SUPPORT=y
FREETZ_AVMDAEMON_DISABLE_NTP=y
FREETZ_PACKAGE_DROPBEAR=y
FREETZ_PACKAGE_DROPBEAR_DISABLE_HOST_LOOKUP=y
FREETZ_PACKAGE_HASERL=y
FREETZ_PACKAGE_IFSTAT=y
FREETZ_PACKAGE_IFTOP=y
FREETZ_PACKAGE_INETD=y
FREETZ_PACKAGE_IPTRAF=y
FREETZ_PACKAGE_IPUTILS=y
FREETZ_PACKAGE_MOD=y
FREETZ_PACKAGE_MOD_ETCSERVICES=y
FREETZ_PACKAGE_MODCGI=y
FREETZ_PACKAGE_NETSNMP=y
FREETZ_PACKAGE_NMAP=y
FREETZ_PACKAGE_NMAP_VERSION_4=y
FREETZ_PACKAGE_NMAP_services=y
FREETZ_PACKAGE_NMAP_WITH_SHARED_LUA=y
FREETZ_PACKAGE_NMAP_WITH_SHARED_PCRE=y
FREETZ_PACKAGE_OPENVPN=y
FREETZ_PACKAGE_OPENVPN_VERSION_2_3=y
FREETZ_PACKAGE_OPENVPN_OPENSSL=y
FREETZ_PACKAGE_OPENVPN_WITH_LZO=y
FREETZ_PACKAGE_OPENVPN_ENABLE_SMALL=y
FREETZ_PACKAGE_OPENVPN_USE_V2_CGI=y
FREETZ_PACKAGE_STUNNEL=y
FREETZ_PACKAGE_TCPDUMP=y
FREETZ_WGET=y
FREETZ_PACKAGE_IPTABLES_IS_SELECTABLE=y
FREETZ_PACKAGE_AUTHORIZED_KEYS=y
FREETZ_PACKAGE_ONLINECHANGED_CGI=y
FREETZ_PACKAGE_OPENVPN_V2_CGI=y
FREETZ_PACKAGE_SYSLOGD_CGI=y
FREETZ_PACKAGE_WOL_CGI=y
FREETZ_LIB_STDCXXLIB=y
FREETZ_LIB_libuClibc__=y
FREETZ_LIB_libcrypto=y
FREETZ_LIB_libssl=y
FREETZ_OPENSSL_VERSION_PROMPT=y
FREETZ_OPENSSL_VERSION_0=y
FREETZ_OPENSSL_SHLIB_VERSION="0.9.8"
FREETZ_LIB_liblzo2=y
FREETZ_LIB_libz=y
FREETZ_LIB_libncurses=y
FREETZ_SHARE_terminfo=y
FREETZ_SHARE_terminfo_ansi=y
FREETZ_SHARE_terminfo_gnome=y
FREETZ_SHARE_terminfo_konsole=y
FREETZ_SHARE_terminfo_linux=y
FREETZ_SHARE_terminfo_putty=y
FREETZ_SHARE_terminfo_rxvt=y
FREETZ_SHARE_terminfo_screen=y
FREETZ_SHARE_terminfo_screenMINUSw=y
FREETZ_SHARE_terminfo_sun=y
FREETZ_SHARE_terminfo_vt100=y
FREETZ_SHARE_terminfo_vt102=y
FREETZ_SHARE_terminfo_vt102MINUSnsgr=y
FREETZ_SHARE_terminfo_vt102MINUSw=y
FREETZ_SHARE_terminfo_vt200=y
FREETZ_SHARE_terminfo_vt220=y
FREETZ_SHARE_terminfo_vt52=y
FREETZ_SHARE_terminfo_xterm=y
FREETZ_SHARE_terminfo_xtermMINUS256color=y
FREETZ_SHARE_terminfo_xtermMINUScolor=y
FREETZ_SHARE_terminfo_xtermMINUSxfree86=y
FREETZ_LIB_libpanel=y
FREETZ_LIB_libdnet=y
FREETZ_LIB_libpcap=y
FREETZ_LIB_libpcre=y
FREETZ_LIB_ld_uClibc=y
FREETZ_LIB_libcrypt=y
FREETZ_LIB_libdl=y
FREETZ_LIB_libm=y
FREETZ_LIB_libpthread=y
FREETZ_LIB_librt=y
FREETZ_LIB_libubacktrace=y
FREETZ_LIB_libuClibc=y
FREETZ_LIB_libutil=y
FREETZ_LIB_libgcc_s=y
FREETZ_LIB_libctlmgr=y
FREETZ_LIB_liblua=y
FREETZ_BUSYBOX__MANDATORY=y
FREETZ_BUSYBOX__MANDATORY_05_XX=y
FREETZ_BUSYBOX__IPV6_UTILS=y
FREETZ_BUSYBOX_HAVE_DOT_CONFIG=y
FREETZ_BUSYBOX_PLATFORM_LINUX=y
FREETZ_BUSYBOX_FEATURE_BUFFERS_GO_ON_STACK=y
FREETZ_BUSYBOX_SHOW_USAGE=y
FREETZ_BUSYBOX_FEATURE_VERBOSE_USAGE=y
FREETZ_BUSYBOX_FEATURE_DEVPTS=y
FREETZ_BUSYBOX_FEATURE_PIDFILE=y
FREETZ_BUSYBOX_PID_FILE_PATH="/var/run"
FREETZ_BUSYBOX_FEATURE_SUID=y
FREETZ_BUSYBOX_FEATURE_PREFER_APPLETS=y
FREETZ_BUSYBOX_BUSYBOX_EXEC_PATH="/bin/busybox"
FREETZ_BUSYBOX_FEATURE_SYSLOG=y
FREETZ_BUSYBOX_FEATURE_HAVE_RPC=y
FREETZ_BUSYBOX_LFS=y
FREETZ_BUSYBOX_CROSS_COMPILER_PREFIX=""
FREETZ_BUSYBOX_SYSROOT=""
FREETZ_BUSYBOX_EXTRA_CFLAGS=""
FREETZ_BUSYBOX_EXTRA_LDFLAGS=""
FREETZ_BUSYBOX_EXTRA_LDLIBS=""
FREETZ_BUSYBOX_NO_DEBUG_LIB=y
FREETZ_BUSYBOX_INSTALL_APPLET_SYMLINKS=y
FREETZ_BUSYBOX_PREFIX="./_install"
FREETZ_BUSYBOX_PASSWORD_MINLEN=6
FREETZ_BUSYBOX_MD5_SMALL=1
FREETZ_BUSYBOX_SHA3_SMALL=1
FREETZ_BUSYBOX_FEATURE_USE_TERMIOS=y
FREETZ_BUSYBOX_FEATURE_EDITING=y
FREETZ_BUSYBOX_FEATURE_EDITING_MAX_LEN=1024
FREETZ_BUSYBOX_FEATURE_EDITING_HISTORY=255
FREETZ_BUSYBOX_FEATURE_TAB_COMPLETION=y
FREETZ_BUSYBOX_FEATURE_EDITING_FANCY_PROMPT=y
FREETZ_BUSYBOX_FEATURE_NON_POSIX_CP=y
FREETZ_BUSYBOX_FEATURE_COPYBUF_KB=64
FREETZ_BUSYBOX_FEATURE_SKIP_ROOTFS=y
FREETZ_BUSYBOX_MONOTONIC_SYSCALL=y
FREETZ_BUSYBOX_IOCTL_HEX2STR_ERROR=y
FREETZ_BUSYBOX_FEATURE_HWIB=y
FREETZ_BUSYBOX_FEATURE_SEAMLESS_GZ=y
FREETZ_BUSYBOX_GUNZIP=y
FREETZ_BUSYBOX_BUNZIP2=y
FREETZ_BUSYBOX_UNXZ=y
FREETZ_BUSYBOX_XZ=y
FREETZ_BUSYBOX_BZIP2=y
FREETZ_BUSYBOX_GZIP=y
FREETZ_BUSYBOX_GZIP_FAST=0
FREETZ_BUSYBOX_TAR=y
FREETZ_BUSYBOX_FEATURE_TAR_CREATE=y
FREETZ_BUSYBOX_FEATURE_TAR_FROM=y
FREETZ_BUSYBOX_FEATURE_TAR_OLDGNU_COMPATIBILITY=y
FREETZ_BUSYBOX_FEATURE_TAR_GNU_EXTENSIONS=y
FREETZ_BUSYBOX_UNZIP=y
FREETZ_BUSYBOX_BASENAME=y
FREETZ_BUSYBOX_CAT=y
FREETZ_BUSYBOX_DATE=y
FREETZ_BUSYBOX_FEATURE_DATE_ISOFMT=y
FREETZ_BUSYBOX_FEATURE_DATE_COMPAT=y
FREETZ_BUSYBOX_ID=y
FREETZ_BUSYBOX_GROUPS=y
FREETZ_BUSYBOX_TEST=y
FREETZ_BUSYBOX_TOUCH=y
FREETZ_BUSYBOX_FEATURE_TOUCH_SUSV3=y
FREETZ_BUSYBOX_TR=y
FREETZ_BUSYBOX_FEATURE_TR_CLASSES=y
FREETZ_BUSYBOX_FEATURE_TR_EQUIV=y
FREETZ_BUSYBOX_CHGRP=y
FREETZ_BUSYBOX_CHMOD=y
FREETZ_BUSYBOX_CHOWN=y
FREETZ_BUSYBOX_CHROOT=y
FREETZ_BUSYBOX_CP=y
FREETZ_BUSYBOX_CUT=y
FREETZ_BUSYBOX_DD=y
FREETZ_BUSYBOX_FEATURE_DD_SIGNAL_HANDLING=y
FREETZ_BUSYBOX_DF=y
FREETZ_BUSYBOX_DIRNAME=y
FREETZ_BUSYBOX_DU=y
FREETZ_BUSYBOX_FEATURE_DU_DEFAULT_BLOCKSIZE_1K=y
FREETZ_BUSYBOX_ECHO=y
FREETZ_BUSYBOX_FEATURE_FANCY_ECHO=y
FREETZ_BUSYBOX_ENV=y
FREETZ_BUSYBOX_EXPR=y
FREETZ_BUSYBOX_FALSE=y
FREETZ_BUSYBOX_HEAD=y
FREETZ_BUSYBOX_FEATURE_FANCY_HEAD=y
FREETZ_BUSYBOX_LN=y
FREETZ_BUSYBOX_LOGNAME=y
FREETZ_BUSYBOX_LS=y
FREETZ_BUSYBOX_FEATURE_LS_FILETYPES=y
FREETZ_BUSYBOX_FEATURE_LS_FOLLOWLINKS=y
FREETZ_BUSYBOX_FEATURE_LS_RECURSIVE=y
FREETZ_BUSYBOX_FEATURE_LS_SORTFILES=y
FREETZ_BUSYBOX_FEATURE_LS_TIMESTAMPS=y
FREETZ_BUSYBOX_FEATURE_LS_USERNAME=y
FREETZ_BUSYBOX_MD5SUM=y
FREETZ_BUSYBOX_MKDIR=y
FREETZ_BUSYBOX_MKFIFO=y
FREETZ_BUSYBOX_MKNOD=y
FREETZ_BUSYBOX_MV=y
FREETZ_BUSYBOX_NICE=y
FREETZ_BUSYBOX_NOHUP=y
FREETZ_BUSYBOX_PRINTENV=y
FREETZ_BUSYBOX_PRINTF=y
FREETZ_BUSYBOX_PWD=y
FREETZ_BUSYBOX_READLINK=y
FREETZ_BUSYBOX_REALPATH=y
FREETZ_BUSYBOX_RM=y
FREETZ_BUSYBOX_RMDIR=y
FREETZ_BUSYBOX_SEQ=y
FREETZ_BUSYBOX_SLEEP=y
FREETZ_BUSYBOX_FEATURE_FANCY_SLEEP=y
FREETZ_BUSYBOX_SORT=y
FREETZ_BUSYBOX_STAT=y
FREETZ_BUSYBOX_FEATURE_STAT_FORMAT=y
FREETZ_BUSYBOX_STTY=y
FREETZ_BUSYBOX_SYNC=y
FREETZ_BUSYBOX_TAIL=y
FREETZ_BUSYBOX_FEATURE_FANCY_TAIL=y
FREETZ_BUSYBOX_TEE=y
FREETZ_BUSYBOX_FEATURE_TEE_USE_BLOCK_IO=y
FREETZ_BUSYBOX_TRUE=y
FREETZ_BUSYBOX_TTY=y
FREETZ_BUSYBOX_UNAME=y
FREETZ_BUSYBOX_UNIQ=y
FREETZ_BUSYBOX_UUDECODE=y
FREETZ_BUSYBOX_WC=y
FREETZ_BUSYBOX_YES=y
FREETZ_BUSYBOX_FEATURE_AUTOWIDTH=y
FREETZ_BUSYBOX_FEATURE_HUMAN_READABLE=y
FREETZ_BUSYBOX_FEATURE_MD5_SHA1_SUM_CHECK=y
FREETZ_BUSYBOX_FGCONSOLE=y
FREETZ_BUSYBOX_RESET=y
FREETZ_BUSYBOX_SETCONSOLE=y
FREETZ_BUSYBOX_WHICH=y
FREETZ_BUSYBOX_AWK=y
FREETZ_BUSYBOX_CMP=y
FREETZ_BUSYBOX_SED=y
FREETZ_BUSYBOX_VI=y
FREETZ_BUSYBOX_FEATURE_VI_MAX_LEN=1024
FREETZ_BUSYBOX_FEATURE_VI_8BIT=y
FREETZ_BUSYBOX_FEATURE_VI_COLON=y
FREETZ_BUSYBOX_FEATURE_VI_YANKMARK=y
FREETZ_BUSYBOX_FEATURE_VI_SEARCH=y
FREETZ_BUSYBOX_FEATURE_VI_USE_SIGNALS=y
FREETZ_BUSYBOX_FEATURE_VI_DOT_CMD=y
FREETZ_BUSYBOX_FEATURE_VI_READONLY=y
FREETZ_BUSYBOX_FEATURE_VI_SETOPTS=y
FREETZ_BUSYBOX_FEATURE_VI_SET=y
FREETZ_BUSYBOX_FEATURE_VI_WIN_RESIZE=y
FREETZ_BUSYBOX_FEATURE_VI_ASK_TERMINAL=y
FREETZ_BUSYBOX_FEATURE_ALLOW_EXEC=y
FREETZ_BUSYBOX_FIND=y
FREETZ_BUSYBOX_FEATURE_FIND_PRINT0=y
FREETZ_BUSYBOX_FEATURE_FIND_MTIME=y
FREETZ_BUSYBOX_FEATURE_FIND_MMIN=y
FREETZ_BUSYBOX_FEATURE_FIND_PERM=y
FREETZ_BUSYBOX_FEATURE_FIND_TYPE=y
FREETZ_BUSYBOX_FEATURE_FIND_XDEV=y
FREETZ_BUSYBOX_FEATURE_FIND_MAXDEPTH=y
FREETZ_BUSYBOX_FEATURE_FIND_NEWER=y
FREETZ_BUSYBOX_FEATURE_FIND_INUM=y
FREETZ_BUSYBOX_FEATURE_FIND_EXEC=y
FREETZ_BUSYBOX_FEATURE_FIND_USER=y
FREETZ_BUSYBOX_FEATURE_FIND_GROUP=y
FREETZ_BUSYBOX_FEATURE_FIND_NOT=y
FREETZ_BUSYBOX_FEATURE_FIND_DEPTH=y
FREETZ_BUSYBOX_FEATURE_FIND_PAREN=y
FREETZ_BUSYBOX_FEATURE_FIND_SIZE=y
FREETZ_BUSYBOX_FEATURE_FIND_PRUNE=y
FREETZ_BUSYBOX_FEATURE_FIND_PATH=y
FREETZ_BUSYBOX_FEATURE_FIND_REGEX=y
FREETZ_BUSYBOX_GREP=y
FREETZ_BUSYBOX_FEATURE_GREP_EGREP_ALIAS=y
FREETZ_BUSYBOX_FEATURE_GREP_FGREP_ALIAS=y
FREETZ_BUSYBOX_FEATURE_GREP_CONTEXT=y
FREETZ_BUSYBOX_XARGS=y
FREETZ_BUSYBOX_FEATURE_XARGS_SUPPORT_CONFIRMATION=y
FREETZ_BUSYBOX_FEATURE_XARGS_SUPPORT_QUOTES=y
FREETZ_BUSYBOX_FEATURE_XARGS_SUPPORT_TERMOPT=y
FREETZ_BUSYBOX_FEATURE_XARGS_SUPPORT_ZERO_TERM=y
FREETZ_BUSYBOX_HALT=y
FREETZ_BUSYBOX_INIT=y
FREETZ_BUSYBOX_FEATURE_USE_INITTAB=y
FREETZ_BUSYBOX_FEATURE_KILL_REMOVED=y
FREETZ_BUSYBOX_FEATURE_KILL_DELAY=0
FREETZ_BUSYBOX_FEATURE_INIT_SYSLOG=y
FREETZ_BUSYBOX_INIT_TERMINAL_TYPE="linux"
FREETZ_BUSYBOX_FEATURE_SHADOWPASSWDS=y
FREETZ_BUSYBOX_USE_BB_CRYPT=y
FREETZ_BUSYBOX_ADDUSER=y
FREETZ_BUSYBOX_FIRST_SYSTEM_ID=100
FREETZ_BUSYBOX_LAST_SYSTEM_ID=999
FREETZ_BUSYBOX_ADDGROUP=y
FREETZ_BUSYBOX_FEATURE_ADDUSER_TO_GROUP=y
FREETZ_BUSYBOX_DELUSER=y
FREETZ_BUSYBOX_DELGROUP=y
FREETZ_BUSYBOX_FEATURE_DEL_USER_FROM_GROUP=y
FREETZ_BUSYBOX_LOGIN=y
FREETZ_BUSYBOX_PASSWD=y
FREETZ_BUSYBOX_FEATURE_PASSWD_WEAK_CHECK=y
FREETZ_BUSYBOX_CRYPTPW=y
FREETZ_BUSYBOX_FEATURE_DEFAULT_PASSWD_ALGO="des"
FREETZ_BUSYBOX_INSMOD=y
FREETZ_BUSYBOX_RMMOD=y
FREETZ_BUSYBOX_LSMOD=y
FREETZ_BUSYBOX_FEATURE_LSMOD_PRETTY_2_6_OUTPUT=y
FREETZ_BUSYBOX_MODPROBE=y
FREETZ_BUSYBOX_FEATURE_CHECK_TAINTED_MODULE=y
FREETZ_BUSYBOX_DEFAULT_MODULES_DIR="/lib/modules"
FREETZ_BUSYBOX_DEFAULT_DEPMOD_FILE="modules.dep"
FREETZ_BUSYBOX_BLKID=y
FREETZ_BUSYBOX_FEATURE_BLKID_TYPE=y
FREETZ_BUSYBOX_DMESG=y
FREETZ_BUSYBOX_FEATURE_DMESG_PRETTY=y
FREETZ_BUSYBOX_FLOCK=y
FREETZ_BUSYBOX_GETOPT=y
FREETZ_BUSYBOX_FEATURE_GETOPT_LONG=y
FREETZ_BUSYBOX_MKSWAP=y
FREETZ_BUSYBOX_MORE=y
FREETZ_BUSYBOX_MOUNT=y
FREETZ_BUSYBOX_FEATURE_MOUNT_VERBOSE=y
FREETZ_BUSYBOX_FEATURE_MOUNT_NFS=y
FREETZ_BUSYBOX_FEATURE_MOUNT_CIFS=y
FREETZ_BUSYBOX_FEATURE_MOUNT_FLAGS=y
FREETZ_BUSYBOX_FEATURE_MOUNT_FSTAB=y
FREETZ_BUSYBOX_PIVOT_ROOT=y
FREETZ_BUSYBOX_SWAPONOFF=y
FREETZ_BUSYBOX_SWITCH_ROOT=y
FREETZ_BUSYBOX_UMOUNT=y
FREETZ_BUSYBOX_FEATURE_UMOUNT_ALL=y
FREETZ_BUSYBOX_FEATURE_MOUNT_LOOP=y
FREETZ_BUSYBOX_FEATURE_MOUNT_LOOP_CREATE=y
FREETZ_BUSYBOX_VOLUMEID=y
FREETZ_BUSYBOX_FEATURE_VOLUMEID_EXT=y
FREETZ_BUSYBOX_FEATURE_VOLUMEID_FAT=y
FREETZ_BUSYBOX_FEATURE_VOLUMEID_NTFS=y
FREETZ_BUSYBOX_SETSERIAL=y
FREETZ_BUSYBOX_UBIMKVOL=y
FREETZ_BUSYBOX_UBIRMVOL=y
FREETZ_BUSYBOX_UBIRSVOL=y
FREETZ_BUSYBOX_UBIUPDATEVOL=y
FREETZ_BUSYBOX_CROND=y
FREETZ_BUSYBOX_FEATURE_CROND_DIR="/var/spool/cron"
FREETZ_BUSYBOX_CRONTAB=y
FREETZ_BUSYBOX_MAKEDEVS=y
FREETZ_BUSYBOX_FEATURE_MAKEDEVS_TABLE=y
FREETZ_BUSYBOX_TIME=y
FREETZ_BUSYBOX_NBDCLIENT=y
FREETZ_BUSYBOX_NC=y
FREETZ_BUSYBOX_NC_EXTRA=y
FREETZ_BUSYBOX_PING=y
FREETZ_BUSYBOX_PING6=y
FREETZ_BUSYBOX_FEATURE_FANCY_PING=y
FREETZ_BUSYBOX_STUN_IP=y
FREETZ_BUSYBOX_WHOIS=y
FREETZ_BUSYBOX_FEATURE_IPV6=y
FREETZ_BUSYBOX_FEATURE_PREFER_IPV4_ADDRESS=y
FREETZ_BUSYBOX_ARP=y
FREETZ_BUSYBOX_ARPING=y
FREETZ_BUSYBOX_BRCTL=y
FREETZ_BUSYBOX_ETHER_WAKE=y
FREETZ_BUSYBOX_FTPGET=y
FREETZ_BUSYBOX_FTPPUT=y
FREETZ_BUSYBOX_HOSTNAME=y
FREETZ_BUSYBOX_HTTPD=y
FREETZ_BUSYBOX_FEATURE_HTTPD_BASIC_AUTH=y
FREETZ_BUSYBOX_FEATURE_HTTPD_AUTH_MD5=y
FREETZ_BUSYBOX_FEATURE_HTTPD_CGI=y
FREETZ_BUSYBOX_FEATURE_HTTPD_CONFIG_WITH_SCRIPT_INTERPR=y
FREETZ_BUSYBOX_FEATURE_HTTPD_ENCODE_URL_STR=y
FREETZ_BUSYBOX_IFCONFIG=y
FREETZ_BUSYBOX_FEATURE_IFCONFIG_STATUS=y
FREETZ_BUSYBOX_FEATURE_IFCONFIG_HW=y
FREETZ_BUSYBOX_FEATURE_IFCONFIG_BROADCAST_PLUS=y
FREETZ_BUSYBOX_IFUPDOWN=y
FREETZ_BUSYBOX_IFUPDOWN_IFSTATE_PATH="/var/run/ifstate"
FREETZ_BUSYBOX_FEATURE_IFUPDOWN_IFCONFIG_BUILTIN=y
FREETZ_BUSYBOX_FEATURE_IFUPDOWN_IPV4=y
FREETZ_BUSYBOX_FEATURE_IFUPDOWN_IPV6=y
FREETZ_BUSYBOX_FEATURE_IFUPDOWN_MAPPING=y
FREETZ_BUSYBOX_INETD=y
FREETZ_BUSYBOX_IP=y
FREETZ_BUSYBOX_FEATURE_IP_ADDRESS=y
FREETZ_BUSYBOX_FEATURE_IP_LINK=y
FREETZ_BUSYBOX_FEATURE_IP_ROUTE=y
FREETZ_BUSYBOX_FEATURE_IP_TUNNEL=y
FREETZ_BUSYBOX_FEATURE_IP_RULE=y
FREETZ_BUSYBOX_NETSTAT=y
FREETZ_BUSYBOX_FEATURE_NETSTAT_PRG=y
FREETZ_BUSYBOX_NSLOOKUP=y
FREETZ_BUSYBOX_ROUTE=y
FREETZ_BUSYBOX_TELNETD=y
FREETZ_BUSYBOX_FEATURE_TELNETD_STANDALONE=y
FREETZ_BUSYBOX_TFTP=y
FREETZ_BUSYBOX_TRACEROUTE=y
FREETZ_BUSYBOX_VCONFIG=y
FREETZ_BUSYBOX_WGET=y
FREETZ_BUSYBOX_FEATURE_WGET_STATUSBAR=y
FREETZ_BUSYBOX_FEATURE_WGET_AUTHENTICATION=y
FREETZ_BUSYBOX_FEATURE_WGET_TIMEOUT=y
FREETZ_BUSYBOX_IOSTAT=y
FREETZ_BUSYBOX_MPSTAT=y
FREETZ_BUSYBOX_PMAP=y
FREETZ_BUSYBOX_PSTREE=y
FREETZ_BUSYBOX_PWDX=y
FREETZ_BUSYBOX_SMEMCAP=y
FREETZ_BUSYBOX_TOP=y
FREETZ_BUSYBOX_FEATURE_TOP_CPU_USAGE_PERCENTAGE=y
FREETZ_BUSYBOX_FEATURE_TOP_CPU_GLOBAL_PERCENTS=y
FREETZ_BUSYBOX_UPTIME=y
FREETZ_BUSYBOX_FREE=y
FREETZ_BUSYBOX_KILL=y
FREETZ_BUSYBOX_KILLALL=y
FREETZ_BUSYBOX_KILLALL5=y
FREETZ_BUSYBOX_PIDOF=y
FREETZ_BUSYBOX_FEATURE_PIDOF_SINGLE=y
FREETZ_BUSYBOX_FEATURE_PIDOF_OMIT=y
FREETZ_BUSYBOX_PS=y
FREETZ_BUSYBOX_FEATURE_PS_WIDE=y
FREETZ_BUSYBOX_FEATURE_PS_LONG=y
FREETZ_BUSYBOX_RENICE=y
FREETZ_BUSYBOX_BB_SYSCTL=y
FREETZ_BUSYBOX_ASH=y
FREETZ_BUSYBOX_ASH_BASH_COMPAT=y
FREETZ_BUSYBOX_ASH_JOB_CONTROL=y
FREETZ_BUSYBOX_ASH_ALIAS=y
FREETZ_BUSYBOX_ASH_GETOPTS=y
FREETZ_BUSYBOX_ASH_BUILTIN_ECHO=y
FREETZ_BUSYBOX_ASH_BUILTIN_PRINTF=y
FREETZ_BUSYBOX_ASH_BUILTIN_TEST=y
FREETZ_BUSYBOX_ASH_CMDCMD=y
FREETZ_BUSYBOX_ASH_OPTIMIZE_FOR_SIZE=y
FREETZ_BUSYBOX_ASH_EXPAND_PRMT=y
FREETZ_BUSYBOX_FEATURE_SH_IS_ASH=y
FREETZ_BUSYBOX_FEATURE_BASH_IS_NONE=y
FREETZ_BUSYBOX_SH_MATH_SUPPORT=y
FREETZ_BUSYBOX_FEATURE_SH_STANDALONE=y
FREETZ_BUSYBOX_FEATURE_SH_NOFORK=y
FREETZ_BUSYBOX_SYSLOGD=y
FREETZ_BUSYBOX_FEATURE_ROTATE_LOGFILE=y
FREETZ_BUSYBOX_FEATURE_REMOTE_LOG=y
FREETZ_BUSYBOX_FEATURE_SYSLOGD_DUP=y
FREETZ_BUSYBOX_FEATURE_SYSLOGD_READ_BUFFER_SIZE=256
FREETZ_BUSYBOX_FEATURE_IPC_SYSLOG=y
FREETZ_BUSYBOX_FEATURE_IPC_SYSLOG_BUFFER_SIZE=16
FREETZ_BUSYBOX_LOGREAD=y
FREETZ_BUSYBOX_FEATURE_LOGREAD_REDUCED_LOCKING=y
FREETZ_BUSYBOX_KLOGD=y
FREETZ_BUSYBOX_FEATURE_KLOGD_KLOGCTL=y
FREETZ_BUSYBOX_LOGGER=y
EXTERNAL_ENABLED=y
EXTERNAL_SUBDIRS=y
EXTERNAL_DYNAMIC=y
EXTERNAL_DYNAMIC_SCRIPTS=y
EXTERNAL_CREATEPAK=y
EXTERNAL_OWN_FILES=""
EXTERNAL_FREETZ_PACKAGE_DROPBEAR=y
EXTERNAL_FREETZ_PACKAGE_IFSTAT=y
EXTERNAL_FREETZ_PACKAGE_IFTOP=y
EXTERNAL_FREETZ_PACKAGE_IPTRAF=y
EXTERNAL_FREETZ_PACKAGE_NETSNMP=y
EXTERNAL_FREETZ_PACKAGE_NMAP=y
EXTERNAL_FREETZ_PACKAGE_OPENVPN=y
EXTERNAL_FREETZ_PACKAGE_STUNNEL=y
EXTERNAL_FREETZ_PACKAGE_TCPDUMP=y
EXTERNAL_FREETZ_LIB_libcrypto=y
EXTERNAL_FREETZ_LIB_libssl=y
EXTERNAL_FREETZ_LIB_libdnet=y
EXTERNAL_FREETZ_LIB_libncurses=y
EXTERNAL_FREETZ_LIB_libpanel=y
EXTERNAL_FREETZ_LIB_liblua=y
EXTERNAL_FREETZ_LIB_liblzo2=y
EXTERNAL_FREETZ_LIB_libpcap=y
EXTERNAL_FREETZ_LIB_libpcre=y
EXTERNAL_FREETZ_LIB_libuClibc__=y
EXTERNAL_FREETZ_LIB_libz=y
FREETZ_LANG_DE=y
FREETZ_LANG_STRING="de"
FREETZ_SECURITY_LEVEL=0
FREETZ_STYLE_COLORED=y
FREETZ_STYLE="colored"
FREETZ_SKIN_legacy=y
FREETZ_SKIN_newfreetz=y
FREETZ_SKIN_phoenix=y
FREETZ_FAVICON_NONE=y
FREETZ_FAVICON_STRING="none"
FREETZ_TAGGING_NONE=y
FREETZ_TAGGING_STRING="none"
FREETZ_MODIFY_AVM_VERSION=y
FREETZ_USER_DEFINED_COMMENT=""
FREETZ_CREATE_SEPARATE_OPTIONS_CFG=y
FREETZ_DOWNLOAD_TOOLCHAIN=y
FREETZ_KERNEL_BINUTILS_2_23=y
FREETZ_KERNEL_GCC_4_8=y
FREETZ_KERNEL_BINUTILS_VERSION="2.23.2"
FREETZ_KERNEL_GCC_VERSION="4.8.4"
FREETZ_TARGET_UCLIBC_0_9_33=y
FREETZ_TARGET_UCLIBC_SUPPORTS_libubacktrace=y
FREETZ_TARGET_UCLIBC_REQUIRES_libubacktrace=y
FREETZ_TARGET_BINUTILS_2_23=y
FREETZ_TARGET_GCC_4_8=y
FREETZ_TARGET_GCC_DEFAULT_AS_NEEDED=y
FREETZ_STDCXXLIB_USE_UCLIBCXX=y
FREETZ_TARGET_UCLIBC_VERSION="0.9.33.2"
FREETZ_TARGET_BINUTILS_VERSION="2.23.2"
FREETZ_TARGET_GCC_MAJOR_VERSION="4.8"
FREETZ_TARGET_GCC_MINOR_VERSION="4"
FREETZ_TARGET_GCC_VERSION="${FREETZ_TARGET_GCC_MAJOR_VERSION}.${FREETZ_TARGET_GCC_MINOR_VERSION}"
FREETZ_GNULIBSTDCXX_VERSION="6.0.19"
FREETZ_STDCXXLIB="uclibcxx"
FREETZ_TARGET_CFLAGS="-Os -pipe -Wa,--trap"
FREETZ_TARGET_UCLIBC_REDUCED_LOCALE_SET=y
FREETZ_TARGET_LFS=y
FREETZ_TOOLCHAIN_MINIMIZE_REQUIRED_GLIBC_VERSION=y
FREETZ_VERBOSITY_LEVEL=2
FREETZ_SIZEINFO_COMPRESSED=y
FREETZ_JLEVEL=2
FREETZ_CHECK_CHANGED=y
FREETZ_SQUASHFS_BLOCKSIZE_65536=y
FREETZ_SQUASHFS_BLOCKSIZE=65536
FREETZ_STRIP_BINARIES=y
FREETZ_STRIP_MODULES_FREETZ=y
FREETZ_DL_SITE_USER=""
FREETZ_DL_TOOLCHAIN_SITE=""
FREETZ_DL_KERNEL_TOOLCHAIN_VERSION="r12822"
FREETZ_DL_KERNEL_TOOLCHAIN_MD5="7070affb933a8b5e5172081d2ee0e5c6"
FREETZ_DL_TARGET_TOOLCHAIN_VERSION="r12822"
FREETZ_DL_TARGET_TOOLCHAIN_MD5="79ed3051023ded7a7c12a8145bfdcf1b"
FREETZ_DL_TOOLCHAIN_SUFFIX="shared-glibc"
FREETZ_DL_KERNEL_SITE=""
FREETZ_DL_KERNEL_SOURCE_ID="7390_06.20"
FREETZ_DL_KERNEL_SOURCE="${FREETZ_DL_KERNEL_SOURCE_ID}-release_kernel.tar.xz"
FREETZ_DL_KERNEL_SOURCE_MD5="742f1710cbb613a0dd48b8f18f0a2890"
FREETZ_DL_SITE="@AVM/fritzbox.fon_wlan_7390/firmware/deutsch,@1&1/7390"
FREETZ_DL_SOURCE="FRITZ.Box_Fon_WLAN_7390.AnnexB.84.06.20.image"
FREETZ_DL_SOURCE_MD5="2b9265b0086a882615d350d1451acaf8"
FREETZ_DL_SOURCE_CONTAINER=""
FREETZ_DL_SOURCE_CONTAINER_MD5=""
FREETZ_AVM_HAS_FIRMWARE_05_2X=y
FREETZ_AVM_HAS_FIRMWARE_05_5X=y
FREETZ_AVM_HAS_FIRMWARE_EWE_05_5X=y
FREETZ_AVM_HAS_FIRMWARE_06_0X=y
FREETZ_AVM_HAS_FIRMWARE_EWE_06_0X=y
FREETZ_AVM_HAS_FIRMWARE_06_2X=y
FREETZ_AVM_HAS_FIRMWARE_LABOR=y
FREETZ_AVM_HAS_LANG_DE=y
FREETZ_AVM_HAS_LANG_EN=y
FREETZ_AVM_HAS_AHA=y
FREETZ_AVM_HAS_DECT=y
FREETZ_AVM_HAS_FHEM=y
FREETZ_AVM_HAS_MYFRITZ=y
FREETZ_AVM_HAS_MULTI_ANNEX=y
FREETZ_AVM_HAS_NAS=y
FREETZ_AVM_HAS_NTFS=y
FREETZ_AVM_HAS_PHONE=y
FREETZ_AVM_HAS_TAM=y
FREETZ_AVM_HAS_TR069=y
FREETZ_AVM_HAS_TR069_FWUPDATE=y
FREETZ_AVM_HAS_UDEV=y
FREETZ_AVM_HAS_UMTS=y
FREETZ_AVM_HAS_USB_HOST=y
FREETZ_AVM_HAS_AURA_USB=y
FREETZ_AVM_HAS_WEBDAV=y
FREETZ_AVM_HAS_WLAN=y
FREETZ_AVM_HAS_IPV6=y
FREETZ_AVM_HAS_PTY_SUPPORT=y
FREETZ_AVM_HAS_PRINTK=y
FREETZ_AVM_HAS_EXT2_BUILTIN=y
FREETZ_AVM_HAS_EXT3_BUILTIN=y
FREETZ_AVM_HAS_RAMZSWAP=y
FREETZ_AVM_HAS_CHRONYD=y
FREETZ_AVM_HAS_E2FSPROGS=y
FREETZ_AVM_HAS_INETD=y
FREETZ_AVM_HAS_LSOF=y
FREETZ_AVM_HAS_OPENSSL=y
FREETZ_AVM_HAS_OPENSSL_VERSION_1=y
FREETZ_AVM_HAS_AR7CFG_V12_MIN=y
FREETZ_AVM_HAS_JUNK_BYTES=y
FREETZ_AVM_HAS_MULTID_LEASES_FORMAT_V2=y
FREETZ_FILESYSTEM_MTD_SIZE=0
FREETZ_AVM_VERSION_06_2X=y
FREETZ_AVM_VERSION_04_XX_MIN=y
FREETZ_AVM_VERSION_05_2X_MIN=y
FREETZ_AVM_VERSION_05_5X_MIN=y
FREETZ_AVM_VERSION_06_0X_MIN=y
FREETZ_AVM_VERSION_06_2X_MIN=y
FREETZ_AVM_VERSION_06_2X_MAX=y
FREETZ_TARGET_ARCH_BE=y
FREETZ_TARGET_ARCH="mips"
FREETZ_TARGET_CROSS="mips-linux-uclibc-"
FREETZ_TARGET_MAKE_PATH="toolchain/target/bin"
FREETZ_KERNEL_CROSS="mips-unknown-linux-gnu-"
FREETZ_KERNEL_MAKE_PATH="toolchain/kernel/bin"
FREETZ_AVM_GCC_4_8=y
FREETZ_AVM_GCC_3_4_MIN=y
FREETZ_AVM_GCC_4_6_MIN=y
FREETZ_AVM_GCC_4_7_MIN=y
FREETZ_AVM_GCC_4_8_MIN=y
FREETZ_AVM_GCC_4_8_MAX=y
FREETZ_AVM_GCC_4_9_MAX=y
FREETZ_KERNEL_VERSION_2_6_28=y
FREETZ_KERNEL_VERSION="2.6.28"
FREETZ_KERNEL_VERSION_2_6_13_MIN=y
FREETZ_KERNEL_VERSION_2_6_19_MIN=y
FREETZ_KERNEL_VERSION_2_6_28_MIN=y
FREETZ_KERNEL_VERSION_2_6_28_MAX=y
FREETZ_KERNEL_VERSION_2_6_32_MAX=y
FREETZ_KERNEL_LAYOUT_IKS=y
FREETZ_KERNEL_LAYOUT="iks"
FREETZ_MODULES_KVER="2.6.28.10"
FREETZ_KERNEL_PATCHES="2.6.28.10"
FREETZ_AVM_UCLIBC_0_9_33=y
FREETZ_AVM_UCLIBC_NPTL_ENABLED=y
FREETZ_AVM_SOURCE_7390_06_20=y
FREETZ_AVM_SOURCE_ID="7390_06.20"
FREETZ_AVM_SOURCE_FOR_KERNEL_LAYOUT_IKS=y
FREETZ_REPLACE_KERNEL_AVAILABLE=y
FREETZ_REPLACE_KERNEL_EXPERIMENTAL=y
FREETZ_REPLACE_MODULE_AVAILABLE=y
FREETZ_TYPE_PREFIX="7390"
FREETZ_TYPE_PREFIX_SERIES_SUBDIR="06_2X"
FREETZ_INSTALL_BASE=y
FREETZ_REPLACE_BUSYBOX=y
FREETZ_CIFS_SUPPORT_AVAILABLE=y
FREETZ_NFS_SUPPORT_AVAILABLE=y
FREETZ_NFS_SUPPORT_AVAILABLE_AS_MODULE=y

SSH Config:

Code:

dev tun
proto tcp-client
secret /tmp/flash/openvpn/static.key
remote <REMOTEHOSTNAME> 1196
ifconfig 192.168.11.194 192.168.11.193

tun-mtu 1500
mssfix
verb 3
cipher AES-128-CBC
comp-lzo
keepalive 10 120
chroot /var/tmp/flash/openvpn
user openvpn
group openvpn
persist-tun
persist-key
script-security 2

PeterPawn · 27 Dez 2014

Schweinebraten schrieb:
Wenn nun avm_pa aktiv ist fehlem mir auch Debugging Möglichkeiten, da die relevanten Pakete nicht vom tcpdump gesehen werden.

Kommen die auch bei aktiviertem AVM-Packetdump nicht am CPU-Port an ? Mir ist so, als hätte ich in irgendeiner Quellcode-Datei mal etwas dazu gesehen, daß beim AVM-Packetdump die Pakete - zusätzlich zum "kurzen Dienstweg" - auch noch an den CPU-Port geroutet werden und dann dort gecaptured werden.

Zu den Folgen des Abschaltens des PA habe ich schon versucht, etwas zu schreiben ... der SIP-Fehler bei Dir klingt für mich aber eher so, daß da nach 30 Minuten die TTL des DNS-Eintrags für den SIP-Server abgelaufen ist und die zu diesem Zeitpunkt aktive DNS-Konfiguration der Box die (erneute) Auflösung des Namens nicht mehr erlaubt (vielleicht eine Folge einer aufgebauten OpenVPN-Verbindung, die zum Zeitpunkt der ersten DNS-Abfrage noch nicht lief).

Das läßt sich ja durch die Abfrage des DNS-Proxy der Box mit "dig" und die Auswertung der TTL für den A-Eintrag des SIP-Servers ziemlich leicht diagnostizieren, ob meine Vermutung stimmen könnte. Auch müßte eine DNS-Abfrage auf der Telnet-Shell der Box nach dem SIP-Server nach Ablauf der TTL des Eintrags dann ja auch von Hand fehlschlagen.

Wenn die Vermutung stimmt, sollte das "Festtackern" der IP-Adresse des SIP-Servers über die /etc/hosts eine Möglichkeit sein, wie man einen schnellen Workaround schaffen kann, wobei es dann für die fehlschlagende DNS-Auflösung ja auch eine Ursache geben müßte.

Schweinebraten · 27 Dez 2014

Hallo,

Ich muss mich erstmal outen, mit den Begriffen VM-Packetdump und CPU-Port kann ich nicht wirklich etwas anfangen.
(vieleicht solle ich das Expert Setting der Menuconfig von freetz nochmals überdenken...)

Die Vermutung, dass ein DNS TTL Problem vorliegt hate ich auch schon. Dagegen spricht aber, dass der DNS für Internet Access noch problemlos geht. Dennoch bin ich der Sache mal nachgegangen, wenn sich eine SIP Nummer registriert, tut sich einiges im DNS:

Code:

07:42:16.098705 IP 192.168.11.1.7077 > 217.0.43.161.53: 61307+ NAPTR? tel.t-online.de. (33)
07:42:16.115290 IP 217.0.43.161.53 > 192.168.11.1.7077: 61307 4/0/0 CNAME ims.voip.t-ipnet.de., CNAME ims001.voip.t-ipnet.de., CNAME m-ipp-a01.isp.t-ipnet.de., NAPTR (167)
07:42:16.119755 IP 192.168.11.1.7077 > 217.0.43.161.53: 5239+ SRV? _sip._udp.tel.t-online.de. (43)
07:42:16.136385 IP 217.0.43.161.53 > 192.168.11.1.7077: 5239 2/0/0 SRV f-epp-009.isp.t-ipnet.de.:5060 0 5, SRV b-epp-009.isp.t-ipnet.de.:5060 1 5 (131)
07:42:16.139283 IP 192.168.11.1.7077 > 217.0.43.161.53: 16894+ A? b-epp-009.isp.t-ipnet.de. (42)
07:42:16.142876 IP 192.168.11.1.7077 > 217.0.43.161.53: 12595+ A? f-epp-009.isp.t-ipnet.de. (42)
07:42:16.155863 IP 217.0.43.161.53 > 192.168.11.1.7077: 16894 1/0/0 A 217.0.23.108 (58)
07:42:16.159786 IP 217.0.43.161.53 > 192.168.11.1.7077: 12595 1/0/0 A 217.0.23.76 (58)

Der Host tel.t-online.net ist als Startpunkt nachvollziebar, er taucht in der Config /var/flash/voip.cfg auf.
Wenn ich nun einen Eintag in die Hosts mache, kann ich nicht sicher sagen das T-online mal aus Redundanzgründen etc. die Auflösung ändert.

ein weiterer Eintrag in der /var/flash/voip.cfg hat mich aufhorchen lassen:

Code:

dnsport = 7077;

Warum hört der voipd auf 7077 dns ?
Das könnte zumindest eine Erklärung sein, warum der DNS sich für internet möglicherweise anders verhält als der DNS für Voip ....
Bleibt aber erstmal Spekulation ...
Das mit der TTL ist auch lustig, nach der Ausgabe von dig hat die Zone eine TTL von 3600, sprich eine Stunde. In der Datei /var/flash/voip.cfg dagegen wird Je Rufnummer eine eigene TTL gesetzt, dies ist auf 10m -> 10 Minuten gesetzt, auch das kann meine Zeitspanne erklären.

Ein Eintrag in die hosts ist für mich ein NoGO, aktuell bin ich am überlegen mittels Cron einige Prüfungen durchzufürhren, um sicherzustellen, dass Telefon geht. Hier bin ich noch auf der Suche nach einer Möglichkeit den Registrierugsstatus einer SIP Rufnummer mittels Commandline herauszufinden. Alternativ werde ich auch auf das OpenVPN verzichten, ein Teil ist schon auf eine PC Engines HW (mit Debian) ausgelagert.
Es bleibt spannend.

Ein Gruss vom Schweinebraten

PeterPawn · 27 Dez 2014

1. Ein Wireshark-kompatibler Packetdump (das ist auch das von tcpdump bei Schreiben mit Option -w verwendete Format) läßt sich auf der Support-Seite des FRITZ!OS (im AVM-GUI) starten und stoppen, das dabei entstehende File kann mit Wireshark (notfalls auch mit einem "ordentlichen" tcpdump-Derivat, das in der Busybox kann u.U. keine Datei laden) analysiert werden. Ist kein großes Ding und da Du offenbar mit der Shell-Version umgehen und deren Ausgaben interpretieren kannst, sicherlich kein unüberwindbares Hindernis.

2. Ich würde nie auf die Idee kommen, einen statischen hosts-Eintrag zu erzeugen. Das ist ohne entsprechende Vorbereitungen ohnehin nicht möglich, eine Modifikation bei jedem Start der Box war der Vorschlag, dieser ist aber auch nur als Workaround (ich spare mir das Attribut "dirty") zu verstehen. Ein "Bäumchen wechsele Dich" bei der Zuordnung von DNS-Namen und IP-Adressen während des laufenden Betriebs wäre zwar auch denkbar bei der Telekom, aber nach einem Neustart der Box dann ebenfalls berücksichtigt. Aber ich finde es in jedem Falle auch besser, wenn Du einfach die Ursachen abstellst und z.B. dafür sorgst, daß vom Port 7077 ausgehende DNS-Abfragen immer über das "dev dsl" an die Server des Providers geroutet werden (also auch bei aktiviertem OpenVPN), dann sollte die Auflösung ja auch bei VPN-Verbindung funktionieren.

Schweinebraten schrieb:
Warum hört der voipd auf 7077 dns ?

3. Warum sollte der voipd bei DNS auf irgendetwas hören ? Wie Du schon aus Deinem Dump oben erkennen kannst, legt diese Einstellung (meine Interpretation, da ich nicht selbst testen und variieren kann also auch nur als solche verstehen) nur fest, von welchem Port aus der voipd mit dem DNS des Providers Kontakt aufnimmt. Ob sich dahinter eine Priorisierung, ein anderer DNS-Server oder eine andere Intention verbirgt, wage ich nicht zu beurteilen.

4. Die verschiedenen TTL-Angaben, von denen Du schreibst, kann ich nicht nachvollziehen. Die TTL der Zone (das wäre der SOA-Record) hat ja erst einmal auch nichts mit der TTL einer konkreten Antwort zu tun.

5. Die Abfrage von SIP-Status per ctlmgr_ctl oder luavar ist kein Problem, als zweite Linie der Verteidigung sicherlich ohnehin keine schlechte Idee (wenn man sich darüber klar ist, wie man die Signalisierung macht, wenn z.B. das Aus der kompletten DSL-Verbindung die Ursache des nicht funktionierenden SIP-Accounts ist und nicht nur die fehlende DNS-Auflösung) und die notwendigen Kommandos könnte man Dir sicherlich auch "nennen". Voraussetzung wäre, daß man genau weiß, was Du am Ende abfragen willst ... eine Möglichkeit, eine ziemlich komplette Liste der SIP-Einstellungen zu erhalten, aus der man dann die richtigen heraussuchen kann, wäre die Verwendung der Abfrage

Code:

sip:settings/sip/list(activated,displayname,registrar,outboundproxy,providername,ID,gui_readonly,webui_trunk_id,username,password,stunserver,authname_needed,outboundproxy_without_
route_header,read_p_asserted_identity_header,dditype,only_call_from_registrar,sipping_interval,tx_packetsize_in_ms,g726_via_3551rfc,ccbs_supported,dtmfcfg,clirtype,protocolprefer,route_always_over_internet,Exten
sionLength,Reception,Trunk,use_internat_calling_numb,mwi_supported,clipnstype)

für ein "query" über "luavar". Das Script dazu findest Du irgendwo im Freetz-Ticket #2499, der Aufruf/die Benutzung ist auch irgendwo in diesem Ticket von mir beschrieben. Irgendwann schaffe ich es bestimmt auch mal, das in einem IPPF-Beitrag zu beschreiben, damit ich mir den Verweis auf das inzwischen recht lange Ticket schenken kann, heute mußt Du Dich da aber noch "durchwühlen" (die Suche im Browser hilft aber beim schnellen Finden, wenn man den Namen des Scripts aus den Anhängen ermittelt hat).

6. Neben der verbalen Beschreibung der Umstände (einzelne Eintragungen in der voip.cfg für TTL ?) und der Ausgabe von "dig" wäre die Präsentation der konkreten Ausgaben begrüßenswert und vor allem mal die Feststellung, ob bzw. was da nach den von Dir erwähnten 30 Minuten in den DNS-Abfragen passiert. Mach doch einfach mal nach 25 Minuten Laufzeit mit dem "Paketmitschnitt" der Box einen Packetdump (1. Internetverbindung) und laß in dieser Zeit ansonsten die Internetverbindung im Rahmen Deiner Möglichkeiten "in Ruhe" (das meint, mach nicht parallel einen Download einer Linux-Distribution o.ä.), dann hält sich die Größe des Dumps auch in Grenzen. Anschließend mit Wireshark die DNS-Abfragen ausfiltern und mit denen vergleichen, die man direkt beim Start der Box (notfalls das DSL-Kabel erst später einstecken, dann findet auch der erste "DNS-Block" entsprechend später statt und kann gespeichert werden) beobachtet hat (idealerweise auch mit Packetdump, dann kann man jederzeit wieder nachschauen und muß das nicht "live" auswerten).

7. Spätestens zum Zeitpunkt der "Nichtauflösung" nach 30 Minuten ist dann noch einmal ein "dig @217.0.43.161 tel.t-online.de any" (Option +recurse ist Standard) unter Beobachtung des Netzwerkverkehrs und mit Präsentation der Ausgabe fällig, wenn man eine Chance haben will zu erkennen, ob und wenn ja woran die DNS-Auflösung scheitert. Daß sich dabei dann nichts anderes ändern darf (insb. bzgl. Routing/VPN), versteht sich sicherlich von selbst.

Schweinebraten · 30 Dez 2014

Guten Morgen,

Erstmal besten Dank für die Hinweise, Mit folgendem Script habe ich das Verhalten nun genauer Untersucht:

Code:

#!/bin/sh
# --------------------------------------------------
#    Testscript um den SIP Status zu pruefen 
#    28.12.2014 
#    Version 0.1 
# --------------------------------------------------

trap '' SIGHUP

# DEBUG=1
LOGFILE="/var/media/ftp/UStor01/logs/SIP.log"
UA1="<SIP_TEL_NUMMER>"
SLEEPTIME=120
SLEEPTIME2=600

#----------------------------------------------------------------


while [ 0 -eq 0 ] ; do

REGISTER=$(/bin/showvoipdstat | grep $UA1 | grep "registered ok" | wc -l)
# REGISTER=$(cat  /var/media/ftp/UStor01/logs/num.txt)


if [ $REGISTER == 1 ]
then 
  {

        if [ $DEBUG ] 
        then 
                date >> $LOGFILE; 
                echo "SIP OK" >> $LOGFILE ;
                /usr/bin/dig @217.0.43.161 tel.t-online.de any >> $LOGFILE ; 
                /usr/bin/logger SIP OK $REGISTER ;
        fi

  };
else
 {  
     DSLCONNECT=$(/sbin/showdsldstat | grep "IPv4: connected since" | wc -l)
#      DSLCONNECT=$(cat  /var/media/ftp/UStor01/logs/dsl.txt)

     if [ $DSLCONNECT -ge 1 ] 
        then
        {  
                /usr/bin/logger SIP not OK
                echo "SIP NOT OK" `date` >> $LOGFILE; 
#               echo "SIP NOT OK" >> $LOGFILE ;
                echo "/bin/showvoipdstat | grep $UA1" `/bin/showvoipdstat | grep $UA1`  >> $LOGFILE ;
                /usr/bin/ctlmgr_ctl r sip settings/sip0/activated >> $LOGFILE ; 
                /usr/bin/dig @217.0.43.161 tel.t-online.de any >> $LOGFILE ; 
                /bin/netstat -anp >> $LOGFILE ;
                /sbin/showdsldstat >> $LOGFILE ;
                
                # Fix it
                /mod/etc/init.d/rc.openvpn stop > /dev/null
                sleep 10
                /mod/etc/init.d/rc.openvpn start > /dev/null
        }
        else 
        { 
        /usr/bin/logger NO DSL
        sleep SLEEPTIME2; 
        }                   
     fi;                
 };
fi

sleep $SLEEPTIME
done 

exit 0

Das Script wird nun über rc.external gestartet. Sämtliche anderen Modifikationen an z.B. avm_pa wurden rückgängig gemacht
Anbei ein exemplarisches Log:
Das System wurde um 22:48 manuell rebootet.

Code:

SIP NOT OK Mon Dec 29 22:58:30 CET 2014

------------------------------------- Log ---------------------------------------
SIP NOT OK Mon Dec 29 22:58:30 CET 2014

([email protected], sipiface=internet): not registered dns error 500 -- reachability 50 % (overinternet)
1
;; Truncated, retrying in TCP mode.

; <<>> DiG 9.8.4-P2 <<>> @217.0.43.161 tel.t-online.de any
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19663
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;tel.t-online.de.               IN      ANY

;; ANSWER SECTION:
tel.t-online.de.        600     IN      CNAME   ims.voip.t-ipnet.de.
ims.voip.t-ipnet.de.    74372   IN      CNAME   ims001.voip.t-ipnet.de.
ims001.voip.t-ipnet.de. 74372   IN      CNAME   m-ipp-a01.isp.t-ipnet.de.
m-ipp-a01.isp.t-ipnet.de. 74372 IN      NAPTR   0 0 "s" "SIP+D2U" "" _sip._udp.tel.t-online.de.

;; Query time: 75 msec
;; SERVER: 217.0.43.161#53(217.0.43.161)
;; WHEN: Mon Dec 29 22:58:30 2014
;; MSG SIZE  rcvd: 167

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 0.0.0.0:xxx             0.0.0.0:*               LISTEN      2172/dropbear
tcp        0      0 127.0.0.1:1011          0.0.0.0:*               LISTEN      1245/telefon
tcp        0      0 127.0.0.1:8888          0.0.0.0:*               LISTEN      1245/telefon
tcp        0      0 127.0.0.1:1011          127.0.0.1:36134         ESTABLISHED 1245/telefon
tcp        0      0 192.168.11.1:46640      217.0.43.161:53         TIME_WAIT   -
tcp        0      0 127.0.0.1:36134         127.0.0.1:1011          ESTABLISHED -
tcp        0      0 192.168.11.1:47614      78.47.40.161:1196       ESTABLISHED 2693/openvpn
tcp        0      0 192.168.11.1:xxx        192.168.11.71:37586     ESTABLISHED 3046/dropbear
tcp        0      0 :::49443                :::*                    LISTEN      1023/upnpd
tcp        0      0 :::5060                 :::*                    LISTEN      1317/voipd
tcp        0      0 :::49000                :::*                    LISTEN      1023/upnpd
tcp        0      0 :::49200                :::*                    LISTEN      1023/upnpd
tcp        0      0 :::80                   :::*                    LISTEN      1018/ctlmgr
tcp        0      0 :::81                   :::*                    LISTEN      1783/httpd-webcfg
tcp        0      0 :::114                  :::*                    LISTEN      2172/dropbear
tcp        0      0 :::46579                :::*                    LISTEN      1018/ctlmgr
tcp        0      0 :::53                   :::*                    LISTEN      1066/multid
tcp        0      0 :::8182                 :::*                    LISTEN      1018/ctlmgr
tcp        0      0 :::8183                 :::*                    LISTEN      1018/ctlmgr
tcp        0      0 :::443                  :::*                    LISTEN      1018/ctlmgr
udp        0      0 0.0.0.0:50055           0.0.0.0:*                           1891/syslogd
udp        0      0 0.0.0.0:161             0.0.0.0:*                           2803/snmpd
udp        0      0 127.0.0.1:323           0.0.0.0:*                           2886/chronyd
udp        0      0 0.0.0.0:67              0.0.0.0:*                           1066/multid
udp        0      0 192.168.11.1:48986      0.0.0.0:*                           1018/ctlmgr
udp        0      0 192.168.11.1:1900       0.0.0.0:*                           1023/upnpd
udp        0      0 0.0.0.0:1900            0.0.0.0:*                           1023/upnpd
udp        0      0 192.168.11.1:1900       0.0.0.0:*                           1018/ctlmgr
udp        0      0 0.0.0.0:1900            0.0.0.0:*                           1018/ctlmgr
udp        0      0 0.0.0.0:41714           0.0.0.0:*                           2803/snmpd
udp        0      0 0.0.0.0:123             0.0.0.0:*                           2886/chronyd
udp        0      0 :::41857                :::*                                1018/ctlmgr
udp        0      0 :::43272                :::*                                1023/upnpd
udp        0      0 :::46619                :::*                                1066/multid
udp        0      0 ::1:161                 :::*                                2803/snmpd
udp        0      0 :::7077                 :::*                                1317/voipd
udp        0      0 :::58292                :::*                                1066/multid
udp        0      0 :::53                   :::*                                1066/multid
udp        0      0 :::57025                :::*                                1472/feedd
udp        0      0 ::1:323                 :::*                                2886/chronyd
udp        0      0 :::5060                 :::*                                1317/voipd
udp        0      0 :::5353                 :::*                                1066/multid
udp        0      0 :::5353                 :::*                                1066/multid
udp        0      0 :::5355                 :::*                                1066/multid
udp        0      0 :::5355                 :::*                                1066/multid
udp        0      0 fe80::3631:c4ff:fe68:3723:1900 :::*                                1023/upnpd
udp        0      0 :::1900                 :::*                                1023/upnpd
udp        0      0 fe80::3631:c4ff:fe68:3723:1900 :::*                                1018/ctlmgr
udp        0      0 :::1900                 :::*                                1018/ctlmgr
udp        0      0 :::33525                :::*                                1142/dsld
udp        0      0 fe80::3631:c4ff:fe68:3723:54264 :::*                                1018/ctlmgr
udp        0      0 :::123                  :::*                                2886/chronyd
raw        0      0 0.0.0.0:2               0.0.0.0:*               2           1066/multid
raw        0      0 0.0.0.0:2               0.0.0.0:*               2           1066/multid
raw        0      0 0.0.0.0:2               0.0.0.0:*               2           1066/multid
raw        0      0 0.0.0.0:2               0.0.0.0:*               2           1066/multid
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags       Type       State         I-Node PID/Program name    Path
unix  2      [ ]         DGRAM                      2559 1018/ctlmgr         /var/tmp/me_TR064.ctl
unix  2      [ ]         DGRAM                      2818 1018/ctlmgr         /var/tmp/me_logic.ctl
unix  2      [ ACC ]     STREAM     LISTENING       1026 653/configd         /var/rpc/configd
unix  2      [ ]         DGRAM                      3076 1317/voipd          /var/tmp/me_voipd.ctl
unix  2      [ ACC ]     STREAM     LISTENING       2577 1178/pbd            /var/tmp/pbctrl
unix  2      [ ACC ]     STREAM     LISTENING       2579 1178/pbd            /var/tmp/pb_event
unix  2      [ ]         DGRAM                      1812 1066/multid         /var/tmp/me_multid.ctl
unix  2      [ ACC ]     SEQPACKET  LISTENING       3349 1472/feedd          /var/tmp/me_feedd_daemon.ctl
unix  2      [ ]         DGRAM                      2581 1178/pbd            /var/tmp/pbmsg
unix  2      [ ]         DGRAM                      2583 1178/pbd            /var/tmp/me_phonebook.ctl
unix  2      [ ]         DGRAM                      1816 996/l2tpv3d         /var/tmp/me_L2TPV3.ctl
unix  10     [ ]         DGRAM                      3865 1891/syslogd        /dev/../tmp/log
unix  2      [ ACC ]     STREAM     LISTENING       3387 -                   /var/rpc/kernel
unix  2      [ ]         DGRAM                      1606 989/avmipcd         /var/tmp/me_remote.ctl
unix  2      [ ]         DGRAM                      1608 989/avmipcd         /var/tmp/me_avmipc_state.ctl
unix  2      [ ]         DGRAM                      5450 2661/hostapd        /var/run/hostapd/ath1
unix  2      [ ACC ]     STREAM     LISTENING       3409 1506/pictured       /var/rpc/pictured_if
unix  2      [ ]         DGRAM                       859 -                   /var/tmp/me_avmdebug.ctl
unix  2      [ ]         DGRAM                      1628 996/l2tpv3d         /var/tmp/me_l2tpv3d.ctl
unix  2      [ ACC ]     SEQPACKET  LISTENING       3170 1302/dect_manager   /var/tmp/dect_manager
unix  2      [ ]         DGRAM                      2915 1245/telefon        /var/tmp/tel_ipc
unix  2      [ ]         DGRAM                      3172 1302/dect_manager   /var/tmp/me_dectmgr.ctl
unix  2      [ ACC ]     SEQPACKET  LISTENING       3437 1516/audiod         /var/tmp/me_audiod.ctl
unix  2      [ ACC ]     STREAM     LISTENING       9340 3046/dropbear       /tmp/dropbear-7a6d7a61/auth-fc4da177-10
unix  2      [ ]         DGRAM                      1932 1086/upnpdevd       /var/tmp/me_upnpdevd.ctl
unix  2      [ ]         DGRAM                      1934 1086/upnpdevd       /var/tmp/me_upnpfboxdesc.ctl
unix  2      [ ACC ]     SEQPACKET  LISTENING       2959 1245/telefon        /var/tmp/foncontrol
unix  2      [ ACC ]     STREAM     LISTENING       2448 1018/ctlmgr         /tmp/plc_sock_if
unix  2      [ ]         DGRAM                      1682 1018/ctlmgr         /var/tmp/me_ctlmgr.ctl
unix  2      [ ACC ]     SEQPACKET  LISTENING       2966 1245/telefon        /var/tmp/tamlua
unix  2      [ ]         DGRAM                      2710 1018/ctlmgr         /var/tmp/me_tr064srv.ctl
unix  2      [ ]         DGRAM                      1961 1086/upnpdevd       /var/tmp/me_upnp_usb.ctl
unix  2      [ ]         DGRAM                      2478 1142/dsld           /var/tmp/me_dsld.ctl
unix  2      [ ]         DGRAM                      5295 2614/hostapd        /var/run/hostapd/ath0
unix  2      [ ]         DGRAM                       577 460/udevd           @/org/kernel/udev/udevd
unix  2      [ ACC ]     STREAM     LISTENING       5578 1101/wland          /var/rpc/wlandrpc
unix  2      [ ]         DGRAM                      3819 1023/upnpd          /var/tmp/me_upnpd.ctl
unix  2      [ ACC ]     STREAM     LISTENING       3070 1018/ctlmgr         /var/rpc/timer_if
unix  2      [ ]         DGRAM                      6654 2886/chronyd        
unix  2      [ ]         DGRAM                      5708 2614/hostapd        
unix  2      [ ]         DGRAM                      5692 2661/hostapd        
unix  2      [ ]         DGRAM                      5684 1245/telefon        
unix  2      [ ]         DGRAM                      5366 1142/dsld           
unix  2      [ ]         DGRAM                      4759 2693/openvpn        
unix  2      [ ]         DGRAM                      4559 2172/dropbear       
unix  2      [ ]         DGRAM                      4189 1893/klogd          
unix  3      [ ]         SEQPACKET  CONNECTED       3610 1472/feedd          /var/tmp/me_feedd_daemon.ctl
unix  3      [ ]         SEQPACKET  CONNECTED       3609 1302/dect_manager   
unix  4      [ ]         STREAM     CONNECTED       3586 1178/pbd            /var/tmp/pb_event
unix  3      [ ]         STREAM     CONNECTED       3585 1178/pbd            /var/tmp/pbctrl
unix  3      [ ]         STREAM     CONNECTED       3584 1302/dect_manager   
unix  3      [ ]         STREAM     CONNECTED       3583 1302/dect_manager   
unix  3      [ ]         STREAM     CONNECTED       3581 1506/pictured       /var/rpc/pictured_if
unix  3      [ ]         STREAM     CONNECTED       3580 1302/dect_manager   
unix  3      [ ]         STREAM     CONNECTED       3562 1018/ctlmgr         /var/rpc/timer_if
unix  3      [ ]         STREAM     CONNECTED       3561 1018/ctlmgr         
unix  3      [ ]         SEQPACKET  CONNECTED       3519 1472/feedd          /var/tmp/me_feedd_daemon.ctl
unix  3      [ ]         SEQPACKET  CONNECTED       3518 1516/audiod         
unix  3      [ ]         SEQPACKET  CONNECTED       3514 1516/audiod         /var/tmp/me_audiod.ctl
unix  3      [ ]         SEQPACKET  CONNECTED       3513 1302/dect_manager   
unix  3      [ ]         STREAM     CONNECTED       3434 653/configd         /var/rpc/configd
unix  3      [ ]         STREAM     CONNECTED       3433 1516/audiod         
unix  3      [ ]         STREAM     CONNECTED       3347 653/configd         /var/rpc/configd
unix  3      [ ]         STREAM     CONNECTED       3346 1472/feedd          
unix  3      [ ]         SEQPACKET  CONNECTED       3288 1245/telefon        /var/tmp/foncontrol
unix  3      [ ]         SEQPACKET  CONNECTED       3287 1302/dect_manager   
unix  3      [ ]         STREAM     CONNECTED       3228 653/configd         /var/rpc/configd
unix  3      [ ]         STREAM     CONNECTED       3227 1302/dect_manager   
unix  3      [ ]         STREAM     CONNECTED       3030 1178/pbd            /var/tmp/pb_event
unix  3      [ ]         STREAM     CONNECTED       3029 1178/pbd            /var/tmp/pbctrl
unix  3      [ ]         STREAM     CONNECTED       3028 1018/ctlmgr         
unix  3      [ ]         STREAM     CONNECTED       3027 1018/ctlmgr         
unix  3      [ ]         STREAM     CONNECTED       2920 1178/pbd            /var/tmp/pb_event
unix  3      [ ]         STREAM     CONNECTED       2919 1178/pbd            /var/tmp/pbctrl
unix  3      [ ]         STREAM     CONNECTED       2918 1245/telefon        
unix  3      [ ]         STREAM     CONNECTED       2917 1245/telefon        
unix  3      [ ]         STREAM     CONNECTED       2587 1178/pbd            
unix  3      [ ]         STREAM     CONNECTED       2586 1178/pbd            
unix  3      [ ]         STREAM     CONNECTED       2006 653/configd         /var/rpc/configd
unix  3      [ ]         STREAM     CONNECTED       2005 1018/ctlmgr         
unix  2      [ ]         STREAM                     1978 2614/hostapd        
unix  3      [ ]         DGRAM                       582 460/udevd           
unix  3      [ ]         DGRAM                       581 460/udevd           
time: 2014-12-29 22:58:30
0: sync_dsl: VDSL (showtime)
 maxspeed     51376000   10048000  51.38Mbit/s  10.05Mbit/s
 actual         138192      11632 138.19Kbit/s  11.63Kbit/s
                                         0.27%        0.12%
cpmacconfig:normal
running (voip=0,tr069=0,tv=0,ntp=0,ipv6=0,ipv4=0,vpn=0)
Active Provider: -
PPPoE Forward: disabled

0: name internet
0: sync_group: sync_dsl
0: iface vdsl PPPoE/26/dsl 34:31:xx:xx:xx:xx stay online 1 vlan 7 (voip) (prop: default internet)
0: IPv6: off
0: IPv4: native
0: IPv4: connected since 2014-12-29 22:48:25 (setup time 5 secs) (connect cnt 1)
0: IPv4: next disconnect 2014-12-30 03:19:17 (in 15647 secs)
0: IPv4: ip x.x.x.x peer x.x.x.x mtu 1492
0: IPv4: masqaddr x.x.x.x
0: IPv4: dns 217.0.43.161 217.0.43.177
0: route x.x.x.x/32 protocol iface
0: route 217.0.43.161/32 protocol dns
0: route 217.0.43.177/32 protocol dns
0: acname MUNA79-ths
0: RX bytes:10907985 pkt error:0 discard:0 filtered:15 dropped:0
0: RX pkts:12873 unicast:12873 multicast:0 broadcast:0
0: TX bytes:664059 pkt error:0 discard:0 filtered:0 dropped:0
0: TX pkts:8133 unicast:8132 multicast:0 broadcast:1

< ...>

Ein weiterer Testlauf vorher brachte folgende Zeitpunkte:
manueller Reboot um 20:05:47
SIP NOT OK Mon Dec 29 20:16:22 CET 2014
SIP NOT OK Mon Dec 29 22:05:50 CET 2014
SIP NOT OK Mon Dec 29 22:24:02 CET 2014

Aktuell läuft das Script noch.

Ich ziehe nun daraus folgende Schlüsse:
1) PeterPawn hat vermutlich recht, dass es sich um ein DNS "Problem" handelt.
2) Die DNS Namen sind aber zu jeder Zeit mittels DIG auflösbar.
3) Das Auftreten ca 10 min nach einem boot ist reproduzierbar, danach kann es weitere Zufällige auftretengeben.
4) Den whireshark Trace habe ich noch nicht gemacht, (die Support Seiten hatte ich rausgeschmissen)
5) dass der VOIP Daemon auf Port 7077 möglicherweise auf DNS anfragen hört ist vermutlich nicht relevant.
6) Aktuell scheine ich der einzigste zu sein, das das Problem hat, mit dem Sript werde ich noch etwas weitersuchen und eventuell noch den Trace machen, würde aber vorschlagen, dass thema nun als Info zu betrachten.

Besten Dank für die Hinweise.

MfG
Schweinebraten

PeterPawn · 30 Dez 2014

Für mich ist

Code:

;; Truncated, retrying in TCP mode.

die entscheidende Zeile.

Offenbar wird beim "normalen" DNS-Kontakt über UDP 53 eine Antwort empfangen, die nicht mehr in ein einzelnes Antwortpaket paßt. Wie das genau passieren kann, wenn selbst die rekursive Abfrage (der erste CNAME-Eintrag mit seiner TTL von 600 Sekunden dürfte das "schwächste Glied in der Kette" sein und der Auslöser für die erneut notwendige Auflösung) nur auf 167 Byte in der Antwort kommt, wird sicherlich der Packetdump verraten. Einige Firewalls haben meines Wissens Schwierigkeiten mit Antworten >512 Byte, die 167 sind schon sehr wenig.

Ich bin auch etwas erstaunt, daß sich die dargestellte DNS-Abfrage mit dem Verweis auf den SRV-Record als "finale Antwort" zufrieden gibt ... ich hätte noch die Abfrage des SRV-Records "_sip._udp.tel.t-online.de." in der Antwort des Servers erwartet, ggf. sogar die Auflösung des im SRV-Record noch einmal aufgeführten Namens (dort sind IP-Adressen und Aliase nicht erlaubt, der SRV-Record muß auf A/AAAA-Records zeigen).

Aber da der DNS-Resolver für den voipd wohl kaum auf TCP umschalten wird, wenn die UDP-Antwort unvollständig ist (das ist imho ein Feature von "dig", kann man mit nslookup oder der passenden Option für "dig", die eine Umschaltung ausschließt, ja jederzeit testen - also nur als "Vermutung" auffassen bitte), könnte das am Ende auch die Ursache des Registrierungsproblems sein.

Auf der anderen Seite hast Du damit bisher nur festgestellt, daß der Telekom-DNS (der u.U. der einzige ist, der für Dich die Adressen der SIP-Server richtig auflösen kann) auch bei aktivierter OpenVPN-Verbindung noch erreichbar ist ... ob er auch derjenige ist, der als "default" befragt wird (die Box sucht sich m.E. immer noch einen von den angebotenen aus und glaubt diesem jede Antwort, solange sie überhaupt eine erhält - wobei das bei VPN-Verbindungen anders laufen könnte, wie zwischendrin schon mal an anderer Stelle diskutiert wurde), kann wieder nur das Beobachten des egress-Traffics auf der dsl-Schnittstelle klären.

Auch die Frage, ob da irgendwelche MTU/MSS-Änderungen (MSS wäre aber nur bei TCP überhaupt relevant) bei aktiver OpenVPN-Verbindung vorgenommen werden, kann man durch bloßes "Anstarren" eher nicht beantworten.

An der "EDNS"-Fähigkeit eines Beteiligten dürfte es ja hoffentlich nicht scheitern ... aber für mehrere NAPTR-Antworten braucht es diese auch. Der voidp wird kaum per "dig" auflösen (die "ausgegrabenen" Antworten landen wohl auch nicht als neuere Einträge im DNS-Cache) und sollte - wenn Telekom-DNS ansonsten geht - eigentlich EDNS beherrschen. Wenn Du aber mit Deiner OpenVPN-Verbindung einen anderen DNS-Server ins Spiel bringen solltest, könnte die Ursache auch in der mangelhaften EDNS-Unterstützung dieses Servers liegen. Das sieht man anhand Deiner Protokolle noch nicht.

Für die genaue Diagnose sind die Infos also noch zu dürftig, aber nach meinem Dafürhalten näherst Du Dich der Ursache immer weiter an.

MaxMuster · 30 Dez 2014

Ein paar Dinge, die mir noch durch den Kopf gingen:
- Du gibst (im dig-Test) den DNS vor, das heisst aber noch nicht, dass die FB den auch nutzt (-> Paket-Dump)
- Nutzt die Telekom auch einen eigenen "Voice-VPC" für die Telefonie? Wenn, wird dann die DNS-Auflösung für Telefonie über diesen oder den "normalen" gemacht? Dementsprechend wäre die Frage, ob man ggf. einen Paketmitschnitt dafür hinbekommt?
- Im OpenVPN nutzt du P2P-IPs, die (zumindest im Standardfall eines 192.168.11.0/24-er Netzes) scheinbar innerhalb des LANs sind ("ifconfig 192.168.11.194 192.168.11.193"). Für einen Tunnel ist das sagen wir mal zumindest "sehr ungewöhnlich".

Schweinebraten · 30 Dez 2014

Guten Abend allerseits,

@MaxMuster: Deine Fragen sind einfacher, daher bekommst Du zuerst Antworten.

1) die FB Box nutzt diesen DNS, wurde von Provider so zugewiesen und in in Antwort 3 dokumentiert.
2) Es gibt keinen eigenen Voice VPC. (Dump siehe unten)
3) ich benutze 192.168.11.0/27, damit sind 192.168.11.194 192.168.11.193 ausserhalb.

Nun noch weiter Infos / Comments zu PeterPawn

Inzwischen gibt es noch folgende Zeiten im Log:
SIP NOT OK Tue Dec 30 09:47:05 CET 2014
SIP NOT OK Tue Dec 30 09:57:17 CET 2014
SIP NOT OK Tue Dec 30 18:03:46 CET 2014

Die OpenVPN Verbindung beeinflusst die DNS Auflösung nicht. Das Setup des VPNs fahre ich an mehreren Standorten mit sehr guten Erfahrungen.
Damit sehe ich die Frage nach MTU/MSS als nicht relevant an, da sie
1) interface bezogen ist und
2) auch nicht im "zufälligen" Wechsel von good Case auf bad Case geändert wird.

Mir stellt sich die Frage welchen DNS Resolver der voipd nun nimmt, im tcpdump in Antwort 3 sehen wir den Source Port 7077, der im voip konfiguriert ist.
Würde das heissen, dass der Voipd den internen Resolver multid umgeht?
Würde aus meiner Sicht Sinn machen, da das eine Erklärung wäre, warum der normale DNS für Clients mit Internet Access immer geht.

Eine Auflösung mittels dig und dem DNS 8.8.8.8 einer bekannten US Firma ergab folgendes Ergebnis:

Code:

root@fritz:/var/media/ftp/UStor01/logs# /usr/bin/dig @8.8.8.8 tel.t-online.de any

; <<>> DiG 9.8.4-P2 <<>> @8.8.8.8 tel.t-online.de any
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21112
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;tel.t-online.de.               IN      ANY

;; ANSWER SECTION:
tel.t-online.de.        517     IN      CNAME   ims.voip.t-ipnet.de.

;; Query time: 29 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Dec 30 18:42:28 2014
;; MSG SIZE  rcvd: 64

root@fritz:/var/media/ftp/UStor01/logs# /usr/bin/dig @8.8.8.8 ims.voip.t-ipnet.de. any

; <<>> DiG 9.8.4-P2 <<>> @8.8.8.8 ims.voip.t-ipnet.de. any
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64869
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;ims.voip.t-ipnet.de.           IN      ANY

;; ANSWER SECTION:
ims.voip.t-ipnet.de.    6501    IN      CNAME   ims001.voip.t-ipnet.de.

;; Query time: 32 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Dec 30 18:42:55 2014
;; MSG SIZE  rcvd: 58

root@fritz:/var/media/ftp/UStor01/logs# /usr/bin/dig @8.8.8.8 ims001.voip.t-ipnet.de. any

; <<>> DiG 9.8.4-P2 <<>> @8.8.8.8 ims001.voip.t-ipnet.de. any
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47460
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;ims001.voip.t-ipnet.de.                IN      ANY

;; ANSWER SECTION:
ims001.voip.t-ipnet.de. 10899   IN      CNAME   m-ipp-a01.isp.t-ipnet.de.

;; Query time: 48 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Dec 30 18:43:15 2014
;; MSG SIZE  rcvd: 68

root@fritz:/var/media/ftp/UStor01/logs# /usr/bin/dig @8.8.8.8 m-ipp-a01.isp.t-ipnet.de. any

; <<>> DiG 9.8.4-P2 <<>> @8.8.8.8 m-ipp-a01.isp.t-ipnet.de. any
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28057
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;m-ipp-a01.isp.t-ipnet.de.      IN      ANY

;; ANSWER SECTION:
m-ipp-a01.isp.t-ipnet.de. 21599 IN      NAPTR   0 0 "s" "SIP+D2U" "" _sip._udp.tel.t-online.de.
m-ipp-a01.isp.t-ipnet.de. 599   IN      A       217.0.16.42

;; Query time: 69 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Dec 30 18:43:40 2014
;; MSG SIZE  rcvd: 112

Die Ergebnisse unterscheiden sich aber nicht wirklich im good und Bad Case.
Möglicherweise hat DIG auch ein Problem mit der Darstellung, oder die Telekom DNS liefern nur X recursive Antworten.

Wenn ich nun beim Telekom DNS weiter nach _sip._udp.tel.t-online.de. fage geht es wie folgt zu:

Code:

root@fritz:/var/media/ftp/UStor01/logs# /usr/bin/dig @217.0.43.161 _sip._udp.tel.t-online.de. any
;; Truncated, retrying in TCP mode.

; <<>> DiG 9.8.4-P2 <<>> @217.0.43.161 _sip._udp.tel.t-online.de. any
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51731
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;_sip._udp.tel.t-online.de.     IN      ANY

;; ANSWER SECTION:
_sip._udp.tel.t-online.de. 600  IN      SRV     1 5 5060 s-epp-109.isp.t-ipnet.de.
_sip._udp.tel.t-online.de. 600  IN      SRV     0 5 5060 f-epp-109.isp.t-ipnet.de.

;; Query time: 27 msec
;; SERVER: 217.0.43.161#53(217.0.43.161)
;; WHEN: Tue Dec 30 19:31:57 2014
;; MSG SIZE  rcvd: 131

root@fritz:/var/media/ftp/UStor01/logs# /usr/bin/dig @217.0.43.161 s-epp-109.isp.t-ipnet.de. any
;; Truncated, retrying in TCP mode.

; <<>> DiG 9.8.4-P2 <<>> @217.0.43.161 s-epp-109.isp.t-ipnet.de. any
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19769
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;s-epp-109.isp.t-ipnet.de.      IN      ANY

;; ANSWER SECTION:
s-epp-109.isp.t-ipnet.de. 600   IN      A       217.0.20.236

;; Query time: 32 msec
;; SERVER: 217.0.43.161#53(217.0.43.161)
;; WHEN: Tue Dec 30 19:32:42 2014
;; MSG SIZE  rcvd: 58

Es wundert mich nicht besoders, dass ich unterschiedliche Ergebnisse bekomme, abhängig ob ich nun im Telekom Netz oder ausserhalb frage.

Ich sehe nun 2 Tasks bei mir:

1) Veränderung des 7077 Ports des Voipd und ein einfacher tcpdump auf DNS -> umgeht der voip den lokalen DNS ?
2) Prüfung der dump über die Support Seite - kann ich mehr sehen?

Mit Ergebnissen werde ich mich wieder melden.

Besten Dank und einen guten Start in 2015.

MfG
SchweineBraten

Schweinebraten · 31 Dez 2014

Tag,

leider hat das Verändern des voip Parameters nicht so funktioniert wie ich wollte, da ich an das config file nicht so einfach herankommen.

Damit blieb "nur" der dump welcher zur Fehleranalyse dienen sollte. Die sicherste Methode das Fehlerbild herzustellen ist ein reboot und ca. 10 min warten.

Nach dem Reboot wurde der Dump gestartet und - oh Wunder - der Fehler trat nicht auf. Damit ist m.E. auch der Dump nicht wirklich aussagekräftig.
In der Datei /proc/net/avm_pa/brief war der Status nun "State : capture". Ein Schelm der Böses dabei denkt.
Ich sehe so keine Möglichkeit mit der AVM Support Funktion einen Dump im Fehlerfall zu ziehen.

Ein TestDump zeigte noch, dass im DIG, welcher von Telekom DNS beantwortet wird, keine IP ist, das ist vermutlich eine Frage der Konfiguration des DNS und benuruhigt mich nicht weiter.

Ich habe dann eine der 6 Telefonnummern von der FB weg genommen und einem SIP SoftPhone im (lokalen) Client Netz gegeben die Registrierung erfolgte problemlos.
Nach einem Reboot der FB trat der Fehler nach 10 min zuverlässig auf, über das SIP SoftPhone mit der direkten Registrierung konnte ich noch telefonieren.
Der Zustand war stabil.

Damit bleibe ich nun bei der These, dass die Namensauflösung des voipd etwas anders geht als die Namensauflösung für Clients etc. und das Problem in der FB zu suchen ist, irgendwo in der Abstimmung zwischen voipd, avm_pa und auch dem openvpn Packet.
Ich werde nun vieleicht noch ein paar Erweiterungen in dem Workaroud vornehmen weitere Untersuchungen sehe ich derzeit nicht als sinnvoll an.

Wie üblich, werfen solche Dumps auch mehr Fragen auf, als sie beantworten, so musste ich feststellen, dass der udp Port 5060 auch fürs Internet offen ist.
So ist mir ein SIP Scanner in den test Dump gerutscht, den ich mal auf dem internen Interface gemacht habe.
In solchen Fällen wünsche ich mit einen vollwertigen iptables .... Das ist aber ein Problem von AVM und nicht von Freetz.
Das was da AVM mit dem dsld macht ist doch etwas zweifelhaft.
Anhang anzeigen sipscanner.zip
Besten Dank.

SchweineBraten

PeterPawn · 31 Dez 2014

Schweinebraten schrieb:
so musste ich feststellen, dass der udp Port 5060 auch fürs Internet offen ist.

Ich will das eigentlich nicht weiter thematisieren, aber was dachtest Du denn, wie an einem All-IP-Anschluß mit Internet-Telefonie die Signalisierung eingehender Anrufe sonst erfolgen sollte ?

Der geänderte Status des PA sollte eigentlich bei Dir keine Rolle spielen, da ja für den auf der FRITZ!Box endenden Verkehr die Acceleration ohnehin nicht greift.

Und selbst wenn der Fehler nach den 10 Minuten nicht aufgetreten ist, muß man dem Packetdump ja trotzdem entnehmen können, was da nach 10 Minuten (nach Ablauf der TTL für den CNAME-Eintrag) an DNS-Abfragen von der Box an die Server geht. Das geänderte Verhalten des PA verlängert ja sicherlich die TTL der DNS-Einträge nicht.

Daß der voipd mit hoher Wahrscheinlichkeit nicht den "normalen Resolver" der FRITZ!Box für die DNS-Abfragen benutzen wird, sieht man ja schon an der Möglichkeit (die nach den vorhergehenden Beiträgen ja offenbar auch funktioniert), den DNS-Sourceport für Abfragen im Zusammenhang mit dem voipd festzulegen. Das wäre für den normalen Resolver (der dürfte auch bei AVM in der uClibc stecken) eine ziemlich neue Möglichkeit - die auch für "Client-Programme" sicherlich nur begrenzt Sinn macht.

Und last, but not least ... wo genau liegen denn Deine Probleme, an die voip.cfg bei einer 7390 mit Freetz heranzukommen ?

Nach dem Ändern der Datei kann man dem voipd auf zwei möglichen Wegen die Änderungen zur Kenntnisnahme vorlegen: Einmal mit Judo (msgsend voidp reload) und einmal mit dem Holzhammer (das läuft am Ende auf ein "kill" und einen Neustart des voipd hinaus, das kann man problemlos auch "zu Fuß" machen und dabei den voipd mit der Option "-v" gleich noch etwas "geschwätziger" machen).

Schweinebraten · 2 Jan 2015

Hallo allerseits,

ich habe nun ausführliche traces gezogen, um meine DNS these nun genauer zu untermauern:

Test 1
Reboot des Systems, openvpn startet automatisch, Fehler tritt nach 10 min auf.
Openvpn restart, danach wird folgender Dump angestossen:

more /proc/net/avm_pa/brief
Version : 4.3.10 2014-09-21
State : enabled
HW State : enable
<...>

tcpdump -nn -v -i dsl -c 300 udp port 53

Code:

9:08:23.774835 IP (tos 0x0, ttl 64, id 40522, offset 0, flags [none], proto UDP (17), length 61)
    192.168.11.1.7077 > 217.0.43.161.53: 16755+ NAPTR? tel.t-online.de. (33)
19:08:23.791436 IP (tos 0x0, ttl 60, id 17311, offset 0, flags [DF], proto UDP (17), length 195)
    217.0.43.161.53 > 192.168.11.1.7077: 16755 4/0/0 tel.t-online.de. CNAME ims.voip.t-ipnet.de., ims.voip.t-ipnet.de. CNAME ims001.voip.t-ipnet.de., ims001.voip.t-ipnet.de. CNAME m-ipp-a01.isp.t-ipnet.de., m-ipp-a01.isp.t-ipnet.de. NAPTR (167)
19:08:23.794470 IP (tos 0x0, ttl 64, id 40523, offset 0, flags [none], proto UDP (17), length 70)
    192.168.11.1.7077 > 217.0.43.161.53: 27649+ A? h-epp-005.isp.t-ipnet.de. (42)
19:08:23.797243 IP (tos 0x0, ttl 64, id 40524, offset 0, flags [none], proto UDP (17), length 70)
    192.168.11.1.7077 > 217.0.43.161.53: 42144+ A? s-epp-005.isp.t-ipnet.de. (42)

Punkt 1: es wird wieder der 7077 Port benutzt. Die Pakete sind aber direkt an den DNS addressiert.
Punkt 2: es fehlen Antwortpakete, der tcpdump zeichnet nicht alles auf.
Punkt 3: da noch die interne Adresse in dem Paketen ist, haben die Pakete den dsld noch nicht passiert.

Der Trace läuft weiter

Code:

19:17:23.842043 IP (tos 0x0, ttl 64, id 40531, offset 0, flags [none], proto UDP (17), length 61)
    192.168.11.1.7077 > 217.0.43.161.53: 63754+ NAPTR? tel.t-online.de. (33)
19:17:23.858607 IP (tos 0x0, ttl 60, id 17317, offset 0, flags [DF], proto UDP (17), length 195)
    217.0.43.161.53 > 192.168.11.1.7077: 63754 4/0/0 tel.t-online.de. CNAME ims.voip.t-ipnet.de., ims.voip.t-ipnet.de. CNAME ims001.voip.t-ipnet.de., ims001.voip.t-ipnet.de. CNAME m-ipp-a01.isp.t-ipnet.de., m-ipp-a01.isp.t-ipnet.de. NAPTR (167)
19:17:23.861832 IP (tos 0x0, ttl 64, id 40532, offset 0, flags [none], proto UDP (17), length 71)
    192.168.11.1.7077 > 217.0.43.161.53: 32454+ SRV? _sip._udp.tel.t-online.de. (43)
19:17:23.879436 IP (tos 0x0, ttl 64, id 40533, offset 0, flags [none], proto UDP (17), length 70)
    192.168.11.1.7077 > 217.0.43.161.53: 23712+ A? h-epp-005.isp.t-ipnet.de. (42)
19:17:23.880568 IP (tos 0x0, ttl 64, id 40534, offset 0, flags [none], proto UDP (17), length 70)
    192.168.11.1.7077 > 217.0.43.161.53: 30003+ A? s-epp-005.isp.t-ipnet.de. (42)

Punkt4: der Abstand ist genau 9 min.
Punkt5: in dem zweiten Teil nun wird nicht nach _sip._udp.tel.t-online.de gefragt.

Test 2)
echo disable > /proc/net/avm_pa/control
more /proc/net/avm_pa/brief
Version : 4.3.10 2014-09-21
State : disabled
tcpdump -nn -v -i dsl -c 300 udp port 53

Code:

19:26:23.954101 IP (tos 0x0, ttl 64, id 40543, offset 0, flags [none], proto UDP (17), length 61)
    192.168.11.1.7077 > 217.0.43.161.53: 53338+ NAPTR? tel.t-online.de. (33)
19:26:23.970821 IP (tos 0x0, ttl 60, id 17304, offset 0, flags [DF], proto UDP (17), length 195)
    217.0.43.161.53 > 192.168.11.1.7077: 53338 4/0/0 tel.t-online.de. CNAME ims.voip.t-ipnet.de., ims.voip.t-ipnet.de. CNAME ims001.voip.t-ipnet.de., ims001.voip.t-ipnet.de. CNAME m-ipp-a01.isp.t-ipnet.de., m-ipp-a01.isp.t-ipnet.de. NAPTR (167)
19:26:23.973816 IP (tos 0x0, ttl 64, id 40544, offset 0, flags [none], proto UDP (17), length 70)
    192.168.11.1.7077 > 217.0.43.161.53: 27152+ A? h-epp-005.isp.t-ipnet.de. (42)
19:26:23.977265 IP (tos 0x0, ttl 64, id 40545, offset 0, flags [none], proto UDP (17), length 70)
    192.168.11.1.7077 > 217.0.43.161.53: 18448+ A? s-epp-005.isp.t-ipnet.de. (42)
19:26:23.990753 IP (tos 0x0, ttl 60, id 17305, offset 0, flags [DF], proto UDP (17), length 86)
    217.0.43.161.53 > 192.168.11.1.7077: 27152 1/0/0 h-epp-005.isp.t-ipnet.de. A 217.0.23.40 (58)
19:26:23.994221 IP (tos 0x0, ttl 60, id 17306, offset 0, flags [DF], proto UDP (17), length 86)
    217.0.43.161.53 > 192.168.11.1.7077: 18448 1/0/0 s-epp-005.isp.t-ipnet.de. A 217.0.23.8 (58)

Punkt 6: Der State des amv_pa hat einfluss auf das Ergebnis die Sichtbarkeit der Pakete im Dump.
Punkt 7: es wird wieder nicht _sip._udp.tel.t-online.de gefragt.

Test 3
Modifikation voip.cfg
cho disable > /proc/net/avm_pa/control
more /proc/net/avm_pa/brief
Version : 4.3.10 2014-09-21
State : disabled
voip.cfg
dnsport = 7078;
cat voip.cfg > /var/flash/voip.cfg
netstat -anp | grep 7077
udp 0 0 :::7077 :::* 1310/voipd
/bin/voipcfgchanged restart
netstat -anp | grep 7078
udp 0 0 :::7078 :::* 1310/voipd

während der modifikation und des restarts lief ein
tcpdump -nn -v -i dsl -c 300 udp port 53

Code:

19:40:06.775981 IP (tos 0x0, ttl 64, id 40557, offset 0, flags [none], proto UDP (17), length 61)
    192.168.11.1.33712 > 217.0.43.161.53: 50804+ NAPTR? tel.t-online.de. (33)
19:40:06.792574 IP (tos 0x0, ttl 60, id 17310, offset 0, flags [DF], proto UDP (17), length 195)
    217.0.43.161.53 > 192.168.11.1.33712: 50804 4/0/0 tel.t-online.de. CNAME ims.voip.t-ipnet.de., ims.voip.t-ipnet.de. CNAME ims001.voip.t-ipnet.de., ims001.voip.t-ipnet.de. CNAME m-ipp-a01.isp.t-ipnet.de., m-ipp-a01.isp.t-ipnet.de. NAPTR (167)
19:40:06.811290 IP (tos 0x0, ttl 64, id 40558, offset 0, flags [none], proto UDP (17), length 71)
    192.168.11.1.33712 > 217.0.43.161.53: 7506+ SRV? _sip._udp.tel.t-online.de. (43)
19:40:06.828505 IP (tos 0x0, ttl 60, id 17311, offset 0, flags [DF], proto UDP (17), length 159)
    217.0.43.161.53 > 192.168.11.1.33712: 7506 2/0/0 _sip._udp.tel.t-online.de. SRV s-epp-005.isp.t-ipnet.de.:5060 0 5, _sip._udp.tel.t-online.de. SRV h-epp-005.isp.t-ipnet.de.:5060 1 5 (131)
19:40:06.834119 IP (tos 0x0, ttl 64, id 40559, offset 0, flags [none], proto UDP (17), length 70)
    192.168.11.1.33712 > 217.0.43.161.53: 58421+ A? h-epp-005.isp.t-ipnet.de. (42)
19:40:06.838195 IP (tos 0x0, ttl 64, id 40560, offset 0, flags [none], proto UDP (17), length 70)
    192.168.11.1.33712 > 217.0.43.161.53: 31733+ A? s-epp-005.isp.t-ipnet.de. (42)
19:40:06.850986 IP (tos 0x0, ttl 60, id 17312, offset 0, flags [DF], proto UDP (17), length 86)
    217.0.43.161.53 > 192.168.11.1.33712: 58421 1/0/0 h-epp-005.isp.t-ipnet.de. A 217.0.23.40 (58)
19:40:06.854726 IP (tos 0x0, ttl 60, id 17313, offset 0, flags [DF], proto UDP (17), length 86)
    217.0.43.161.53 > 192.168.11.1.33712: 31733 1/0/0 s-epp-005.isp.t-ipnet.de. A 217.0.23.8 (58)

Punkt 8: nun werden freie Ports gewählt.

Test 4
reboot mit o.veränderter Konfiguration
echo disable > /proc/net/avm_pa/control
tcpdump -nn -v -i dsl -c 300 -w /var/media/ftp/UStor01/logs/dump_test4.pcap udp port 53

Testdauer 20 min - kein DNS Request für SIP, Fehlerfall tritt nach ca. 10 ein.

Test 5
anschliessend an 4 -> erneuter Start des Dumps mit
tcpdump -nn -v -i dsl -c 300 -w /var/media/ftp/UStor01/logs/dump_test5.pcap udp port 53

und Stop der openvpn
/mod/etc/init.d/rc.openvpn stop

Fehlerfall nach ca. 10 sec beseitigt.
Trace stopped.

Punkt 9: in diesem Trace wird NUR der sourcePort 7078 verwendet.

Test 6
Ziel Reproduktion dieses Verhaltens mit Port 7077 (original konfig)
änderung Voip.cfg
dnsport = 7077;
cat voip.cfg > /var/flash/voip.cfg
reboot
echo disable > /proc/net/avm_pa/control
tcpdump -nn -v -i dsl -c 300 -w /var/media/ftp/UStor01/logs/dump_test6.pcap udp port 53

10) wieder keine DNS Abfragen für SIP

Test 7
Ziel mit der ersten Auflösung von SIP
Physikalische Trennung von DSL
openvpn bleibt auf automatischen Start
reboot
echo disable > /proc/net/avm_pa/control
tcpdump -nn -v -i dsl -c 300 -w /var/media/ftp/UStor01/logs/dump_test7.pcap udp port 53
Test wird mindestens 20 min laufen gelassen.

Ergebniss: Fehler tritt nach ca. 10 min NICHT auf.

Test 8
Normaler Betrieb,
Reboot, dann sofort Dump über avm Support Seite - Routingschnittstelle
Datei dump_test8.pcap

Ergebniss: Fehler tritt nach ca. 10 min auf.
11) Ein Dump mittels avm Routing Interface und
"tcpdump -nn -v -i dsl -c 300 -w xxxxxxx port 53" ist gleichwerting
(solange der CLI Trace nicht in die Packetbegrenzung von 300 Paketen läuft)

Test 9
Nach direkt nach Test 8 wird nun über AVM Support die Internetverbindung Schnittstelle 0 getract.
Fehler liegt immer noch an.
Ziel Nachweis, dass auch indem internet dump nicht nach SIP Hosts gefragt wird.

auch dieser Dump lief für mehr als 10 min und es wurde kein DNS Request für SIP aufgezeichnet.
Dump ist nicht anbei.

Fazit:
Wie schon vermutet, ist die Wahrscheinlichkeit, dass das voipd seine DNS Anfragen direkt sendet nun
sehr hoch. Im Fehlerfall bleiben diese DNS Anfragen einfach aus - oder werden woanders hin gesendet.

Schon vorher wurde nachgewiesen, dass eine Auflösung der nötigen Namen jederzeit möglich ist. (dig)
Das avm_pa Kernel Modul hat einen Einfluss auf Dumpergebnisse, aber nur bedingt auf das Verhalten.

Mir gehen nun die Ideen aus.

MfG
MSchweinebraten

Anhang anzeigen dumps_test4_8.zip

PeterPawn · 2 Jan 2015

Schweinebraten schrieb:
Punkt 2: es fehlen Antwortpakete, der tcpdump zeichnet nicht alles auf.
Punkt 3: da noch die interne Adresse in dem Paketen ist, haben die Pakete den dsld noch nicht passiert.
Punkt 6: Der State des amv_pa hat einfluss auf das Ergebnis die Sichtbarkeit der Pakete im Dump.

Wenn Du den tcpdump am dsl-Interface ansetzen läßt (das ist dann praktisch die "CPU-Seite" des WAN-Interfaces), "sieht" der natürlich auch nur die Pakete, die am dsl-Interface ankommen und seitens der FRITZ!Box gesondert behandelt werden sollen/müssen (d.h. fast alles jenseits von NAT, was - nach meinem Verständnis des "fast routing codes" - in erster Linie der Effekt des PA ist). Wenn eine AVM-Komponenten über 'dev lan' eine Verbindung nach außen aufbaut und dann durch den PA das entsprechende Antwortpaket auch direkt nach 'dev lan' "ausgeliefert" wird, dann kann das naturgemäß nicht am 'dev dsl' sichtbar sein. Das dürfte auch genau der Grund sein, warum der Zustand "AVM packet dump in progress" vom PA gesondert behandelt wird. Die Vermutung, daß da einfach die Pakete zum 'dev dsl' gespiegelt werden, damit sie aufgezeichnet werden können (wahrscheinlich sogar mit passendem Tagging, damit die am Ende wirklich nur aufgezeichnet und nicht noch einmal geroutet werden), ist sicherlich legitim.

Meine Aussage (oder Vermutung, um das etwas zu relativieren) bezog sich aber eindeutig darauf, ob es einen Unterschied am 'dev lan' macht, ob ein Packetdump auf 'dev dsl' läuft oder nicht. Wenn das tatsächlich einen Unterschied machen würde, hätte man das alte Problem, daß die Messung bereits den gemessenen Wert beeinflußt. Da es dafür eigentlich in diesem Falle keine Notwendigkeit gibt, wäre das - meine Meinung - schon sehr seltsam.

dnsport = 7078;
cat voip.cfg > /var/flash/voip.cfg
netstat -anp | grep 7077
udp 0 0 :::7077 :::* 1310/voipd
/bin/voipcfgchanged restart
netstat -anp | grep 7078
udp 0 0 :::7078 :::* 1310/voipd

Da dort offenbar "nur" ein Reload der Konfiguration stattgefunden hat (PID des voipd ist identisch vor und nach dem "restart"), würde ich diesem Test nicht allzu viel Aussagekraft zugestehen wollen. Wenn man das wirklich richtig testen will, welchen Einfluß die Änderung des DNS-Ports auf den voipd hat, sollte man es noch einmal ausführen, dann allerdings mit einem richtigen Restart des voipd.

Auch der Rückschluß aus nicht stattgefundenen Abfragen ist in meinen Augen nicht unbedingt aussagekräftig. Eine fehlgeschlagene DNS-Abfrage kann den Fehler verursachen, eine nicht stattgefundene (wenn sie nicht aus irgendeinem Grund auf einem falschen Interface oder zum falschen Server erfolgt) kann genauso gut auf einen noch gültigen Eintrag im Cache zurückzuführen sein (wenn der voipd solche Angaben überhaupt berücksichtigt).

Dein Testcase 4/5 spricht ja eher dafür, daß die DNS-Abfragen des voipd über ein falsches Interface gehen, sobald der OpenVPN-Service aktiv ist. Das siehst Du mit einem Capture auf 'dev dsl' dann natürlich nicht als Traffic zum UDP-Port 53, wenn das nur nach Verschlüsselung durch den OpenVPN-Daemon dort ankommt.
Beim Testcase 5 sieht man dann auch, daß mein o.a. Einwand mit dem Unterschied zwischen 'reload' und 'restart' bestätigt wird (in meinen Augen jedenfalls, wenn ich die Feststellung in Punkt 9 richtig interpretiere).

Bei Case 6 steht nicht, ob das mit oder ohne OpenVPN ist ... ich tippe mal auf "mit".

Test 7 verstehe ich die Bedingungen nicht.

Feststellung 11 ist vollkommen logisch, denn das ist genau die CPU-Seite des DSL-Interfaces. "Nach außen" schließen sich da dann die logischen Interfaces an (i.d.R. internet und voip) und von da gehen die Daten dann zum "richtigen" WAN-Interface (wird als "1. Internetverbindung" angezeigt).

Am Ende verdichtet sich für mich eigentlich nur die Erkenntnis, daß bei aktiviertem OpenVPN die DNS-Abfragen über das falsche Interface erfolgen, was man anhand der Routing-Table ja eigentlich leicht feststellen kann. Daß bei einem über das tap-/tun-Interface getunnelten DNS-Request nichts mit dem AVM-Packetdump oder 'tcpdump' zu sehen ist, ist ja der Sinn des VPN.

Solltest Du irgendwo schon eine VPN-Konfiguration in diesem Thread haben, ist das sicherlich nicht unbedingt mehr der letzte Stand und Du solltest - neben der aktuellen VPN-Konfiguration - dann vielleicht mal etwas zu den aktuellen Routing-Einstellungen ermitteln, besonders zum Unterschied zwischen "aktivem" und "nicht aktivem" OpenVPN-Service (ist das bei Dir überhaupt ein Server auf der FB oder ist die Box selbst Client ?). Auch die Abfrage der aktuellen DNS-Server-Einstellungen (entweder zu Fuß oder - besser - aus den Support-Daten der Box extrahiert) ist sicherlich hilfreich ... schon damit man weiß, welcher Server eigentlich befragt werden sollte.
Wenn meine Vermutung mit dem falschen Interface für die DNS-Abfragen stimmt, sollten diese in einem 'tcpdump' für das tap-/tun-Interface ja sichtbar sein ... da funkt auch der PA nicht dazwischen.

Wie schon vermutet, ist die Wahrscheinlichkeit, dass das voipd seine DNS Anfragen direkt sendet nun sehr hoch. Im Fehlerfall bleiben diese DNS Anfragen einfach aus - oder werden woanders hin gesendet.

Ersteres ist - wieder nur meine Meinung, aber schon früher begründet - ja eigentlich schon klar ... kein "normaler Client" kann dem Resolver-Code in der StdLib den Sourceport für "gethostbyname" (oder was auch immer am Ende verwendet wird) vorgeben. Beim zweiten Teil ist die Annahme "werden woanders hin gesendet" ja wesentlich logischer als "keine Abfrage".

Die Aussage

Schweinebraten schrieb:
Mir gehen nun die Ideen aus.

kann ich nicht so richtig nachvollziehen. Du hast das doch nun definitiv auf ein DNS-Problem heruntergebrochen (auch wenn das offenbar sehr viel Aufwand war und die sich immer mehr herauskristallisierende Ursache schon in #2 genannt wurde) und mußt doch eigentlich nur noch die OpenVPN-Konfiguration so vornehmen, daß die DNS-Abfragen des voipd nicht über den Tunnel gehen oder - als Alternative - auch von dort richtig beantwortet werden. Welche Ideen meinst Du ansonsten ?

EDIT:
BTW: Das in #4 mal erwähnte Lua-Script habe ich hier inzwischen beschrieben ... wenn Du am Ende weiter die SIP-Accounts überwachen willst, kann es Dir (i.V.m. einer ggf. modifizierten Abfrage aus #4) vielleicht dabei helfen.

l1800turbo · 17 Mrz 2015

Scheinbar stehe ich nun vor einem ähnlichen Problem.
Nachdem die Telekom den Anschluss auf IP umgestellt hat und ich wegen dem tollen Annex J-Standard einen anderen Router brauchte, hab ich eine Fritz!Box 7390 geholt.

Ich habe, wie vorher auch, openVPN eingerichtet und die SIP-Nummern eingetragen. Wenn ein VPN-Client eingeloggt ist und eine Aktualisierung an der Konfiguration der SIP-Einstellungen stattfindet, hab ich den obigen Effekt:
Anmeldung der Internetrufnummer 0xxxxx war nicht erfolgreich. Ursache: DNS-Fehler

Wenn ich den VPN-Server neu starte, registriert sich der SIP-Client direkt wieder.

Hat sich da schon etwas neues ergeben? Wäre das dann ein openVPN-Bug oder wo muss man sowas zuordnen..

Danke

Schweinebraten · 22 Mrz 2015

Hallo,
da ich aus anderen Gründen noch eine zweite Box (PCEngines) in meinem Netz benötige, habe ich die OpenVPN Sachen von der Fritz Box heruntergenommen.

Nebenbei ergaben einige Tests, dass ich das Problem aber mit der 6.23 Release (als Freetz Grundlage) als auch mit der aktuellen Labor Release noch nachvollziehen kann. Auch habe ich die OPenVPN Config auf ein minimum beschränkt.

Bei meinem Setup war die Fritzbox OPENVPN Client, wenn ich Deine Nachricht lese, scheint die Box server zu sein. ist das richtig?
Damit kann ich aktuell keine genauen Angaben zur Ursache noch eine Lösung bieten. Aktuell steht diese Box ca. 500 km entfernt und der remote Zugriff erfolgt durch den OPenVPN Tunnel, da sind aktuell meine Möglichkeiten zu Testen sehr eingeschränkt.
Gerne würde ich mal Dein openvpn.conf sehen ...

MfG
SchweineBraten

ernsth · 4 Sep 2015

Hallo,

nur also Dokumentation möchte ich meine Erkenntnisse hinzu fügen. Vielleicht hilft es ja jemandem...

Ich konnte das Problem auch reproduzieren. Openvpn Serverdaemon aktiviert, eine IP Nummer deaktiviert wieder aktiviert und diese Nummer konnte sich nicht registrieren -> DNS Fehler.

Durch Zufall hatte ich mal den voipd gestoppt und wieder gestartet und danach passiert das nicht mehr. Egal ob openvpn läuft oder nicht. Ich mache jetzt folgendes:

rc.custom:

Code:

(sleep 60; /bin/voipd -s && /bin/voipd) &

Eine Minute nach dem Boot wird der voipd mal neu gestartet und danach ist die Sache stabil.

Gruß
Hanno

Languages

Suche

Languages

Suche

[Frage] SIP Regisration / OpenVPN ?

Schweinebraten

Neuer User

PeterPawn

IPPF-Urgestein

Schweinebraten

Neuer User

PeterPawn

IPPF-Urgestein

Schweinebraten

Neuer User

PeterPawn

IPPF-Urgestein

MaxMuster

IPPF-Promi

Schweinebraten

Neuer User

Schweinebraten

Neuer User

PeterPawn

IPPF-Urgestein

Schweinebraten

Neuer User

PeterPawn

IPPF-Urgestein

l1800turbo

Neuer User

Schweinebraten

Neuer User

ernsth

Neuer User

Zurzeit aktive Besucher

Neueste Beiträge

Statistik des Forums