AVM verwendet netfilter/iptables - woher kommen die Regeln ?

[JohnDoe42]

Hallo zusammen,

nach einigem Herumüberlegen würde ich gerne die obige Frage ans Forum stellen.
Ich stelle mir beispielsweise vor, daß doch Regeln der Art

iptables -t nat -A POSTROUTING -o dsl -j MASQUERADE

für 's Internet-Surfen und/oder

iptables -t nat -A PREROUTING -i dsl -p tcp --dport 80 -j DNAT --to-destination 192.168.178.11

für ein Port-Forwarding auf einen http-Server irgendwie in der Box realisiert sein könnten/müssten .. (?)
Angenommen, das wäre so: Wären diese Regeln mit Freetz-Mitteln aufzustöbern ?
Und desweiteren evtl. hiermit die Problematik mit dem Packet Accelerator irgendwie zu patchen/umgehen ?
Denn dieses Modul (avm_pa.ko) müßte ja dann doch auch geladen und benutzt werden ... ?
Grüße,

JD.

Edit: Okay, nach Durchsicht der 05.05er-Source kann ich feststellen, daß AVM tatsächlich netfilter verwendet (so schlau war ich früher schon mal - blöder Alzheimer).
Unter \linux-2.6.28\net\avm_pa gibt 's schon mal die Source zu dem bewußten Modul.
Hat denn nun jemand eine Ahnung, wann (bei einer nicht gefreetzten Box) netfilter/iptables mit Regeln gefüttert wird ? Wenn ich beispielsweise im AVM-Firewall-Paket von Freetz eine Portweiterleitung einrichte, mündet dieses ja wohl zumindest in einen Eintrag in der ar7.cfg. Trotzdem muß doch zumindest die Internet-Surf-Regel schon vorher irgendwo fest verdrahtet werden ... (?)

 

[MaxMuster]

Die "normale Nat" macht AVM nicht über iptables sondern das ist innerhalb des "dsld", der auch die "Firewall" macht. Nur den PA-Teil scheint AVM mit netfilter/iptables zu machen...

 

[JohnDoe42]

Hallo Jörg,

vielen Dank für Deinen Hinweis. Verstehe ich das dann richtig, dass AVM das avm_pa.ko fest in den Kernel einbaut, defaultmäßig lädt und dafür dann irgendwo Regeln bereitstellt? Hast Du evtl. eine Idee, wo das Modul sich in den Kernel "einhooked"? Und ganz blöde Frage zum Schluss: Ich nehme an, das ein

rmmod avm_pa

Blödsinn ist...?
Grüße,

JD.

 

[MaxMuster]

Da es kein Modul ist, sondern fest im Kernel, wird es nicht geladen und man kann es auch nicht "entladen".

Ein "kurzer Blick" (suche nach den avm_pa) legt nahe, dass die Einstellungen über "/proc/net/avm_pa/" läuft und vom ctlmgr gesteuert wird. Geht aber scheinbar auch "per Hand":

root@fritz:/var/mod/root# cat /proc/net/avm_pa/brief 
Version        : 2.7.4 2012-03-29
State          : disabled
BSessions      : 0
Sessions       : 0
Max Sessions   : 0
Sessions (dead): 0
Sessions (free): 255
Queuelen       : 0
Rx pkts/secs   : 0
Fw pkts/sec    : 0
Ov pkts/sec    : 0
Rx pakets      : 0
Rx bypass      : 0
Rx search      : 0
Rx match       : 0
Rx modified    : 0
Fw pakets      : 0
Fw local       : 0
VPID1 : RX          0 TX          0 wan
VPID2 : RX          0 TX          0 eth0
VPID3 : RX          0 TX          0 ath0
VPID4 : RX          0 TX          0 wdsdw1
root@fritz:/var/mod/root# cat /proc/net/avm_pa/status 
State          : disabled
Loadcontrol    : idle
IDLE mswin     : 10 50
IRQ mswin      : 550 650
TelephonyReduce: 25
Maxrate        : 5000
TBF            : disabled
Limit Rate     : 5000
Current Rate   : 0
user msecs/sec : 0
idle msecs/sec : 0
irq msecs/sec  : 0
root@fritz:/var/mod/root# cat /proc/net/avm_pa/control 
root@fritz:/var/mod/root# echo enable > /proc/net/avm_pa/control 
root@fritz:/var/mod/root# cat /proc/net/avm_pa/brief 
Version        : 2.7.4 2012-03-29
State          : enabled
BSessions      : 0
Sessions       : 4
Max Sessions   : 4
Sessions (dead): 0
Sessions (free): 251
Queuelen       : 0
Rx pkts/secs   : 10
Fw pkts/sec    : 9
Ov pkts/sec    : 0
Rx pakets      : 139
Rx bypass      : 16
Rx search      : 123
Rx match       : 116
Rx modified    : 0
Fw pakets      : 116
Fw local       : 116
VPID1 : RX          0 TX          0 wan
VPID2 : RX        116 TX          0 eth0
VPID3 : RX          0 TX          0 ath0
VPID4 : RX          0 TX          0 wdsdw1
root@fritz:/var/mod/root# echo disable > /proc/net/avm_pa/control 
root@fritz:/var/mod/root# cat /proc/net/avm_pa/brief 
Version        : 2.7.4 2012-03-29
State          : disabled
BSessions      : 0
Sessions       : 0
Max Sessions   : 6
Sessions (dead): 0
Sessions (free): 255
Queuelen       : 0
Rx pkts/secs   : 12
Fw pkts/sec    : 11
Ov pkts/sec    : 0
Rx pakets      : 320
Rx bypass      : 32
Rx search      : 288
Rx match       : 274
Rx modified    : 0
Fw pakets      : 274
Fw local       : 274
VPID1 : RX          0 TX          0 wan
VPID2 : RX        274 TX          0 eth0
VPID3 : RX          0 TX          0 ath0
VPID4 : RX          0 TX          0 wdsdw1
root@fritz:/var/mod/root#

 

[JohnDoe42]

Hallo Jörg,

ich hätte noch zwei Nachfragen:

1. Ist der Status "disabled" der default ?
2. Macht es Sinn, den Quelltext von avm_pa nach hinsichtlich der Größenänderung von skbuff (weiter) zu analysieren, um so ggfs. das Problem zu patchen ?

Ich glaube verstanden zu haben, das avm_pa den Aufruf von NF_IP_PRE_ROUTING komplett durch eigene Routinen ersetzt...
Grüße,

JD.

 

[MaxMuster]

Hi,

1. Weiß nicht, nutze keine Box damit "im DSL-Betrieb"
2. Wen wirklich avm_pa das conntrack ausschließt, wird das nicht am skbuff liegen. Hab das nicht weiter geprüft, aber wenn hier wirklich NF_IP_PRE_ROUTING ersetzt wird, dürfte das eher der Grund sein...

Habe das aber nicht genauer angesehen

 

[JohnDoe42]

Hallo zusammen,

evtl. noch mal ein Beitrag zur skbuff-Problematik:
Nachdem ich auf meiner 7270 mal die Syslogs nach einem Verbindungsaufbau via OpenVPN genauer angeschaut habe, fand ich u.A. Folgendes:

Jul 16 11:02:25 fritz kern.warn kernel: SKB Header too small --> proto: 8, headroom: 16, need: 46, head: 95514000, data: 95514010, tail: 95514038, end: 95514040, len: 40
...
Jul 16 11:02:25 fritz kern.warn kernel: [<942fbe04>] netif_receive_skb+0x380/0x548

Hier mal der ganze Abschnitt:

Jul 16 11:02:25 fritz kern.warn kernel: SKB Header too small --> proto: 8, headroom: 16, need: 46, head: 95514000, data: 95514010, tail: 95514038, end: 95514040, len: 40
Jul 16 11:02:25 fritz kern.warn kernel: ------------[ cut here ]------------
Jul 16 11:02:25 fritz kern.warn kernel: WARNING: at /home/hjortmann/SELL11/RELEASE_WLAN_TOOLS_ur8_build/driver/core/net80211/ieee80211_output.c:1489 ieee80211_encap_normal+0x6cc/0x103c [wlan]()
Jul 16 11:02:25 fritz kern.warn kernel: Modules linked in: wlan_scan_ap wlan_acl wlan_wep wlan_tkip wlan_ccmp wlan_xauth ath_pci ath_spectral(P) ath_rate_atheros(P) wlan ath_dfs(P) ath_hal(P) avm_ath_extensions(P) xt_tcpudp xt_MARK xt_mark xt_mac ipt_REJECT ipt_LOG ip
Jul 16 11:02:25 fritz kern.warn kernel: Call Trace:
Jul 16 11:02:25 fritz kern.warn kernel: [<94113344>] dump_stack+0x8/0x34
Jul 16 11:02:25 fritz kern.warn kernel: [<9412d97c>] warn_slowpath_common+0x84/0xb0
Jul 16 11:02:25 fritz kern.warn kernel: [<c050f2e0>] ieee80211_encap_normal+0x6cc/0x103c [wlan]
Jul 16 11:02:25 fritz kern.warn kernel: [<c050fca0>] ieee80211_encap+0x50/0x204 [wlan]
Jul 16 11:02:25 fritz kern.warn kernel: [<967553e8>] ath_tx_xmit_normal+0x58/0x4c8 [ath_pci]
Jul 16 11:02:25 fritz kern.warn kernel: [<96756a18>] owl_hardstart+0xc24/0xcc4 [ath_pci]
Jul 16 11:02:25 fritz kern.warn kernel: [<943b7968>] br_dev_queue_push_xmit+0x6c/0x80
Jul 16 11:02:25 fritz kern.warn kernel: [<943b7878>] br_flood+0xc0/0x144
Jul 16 11:02:25 fritz kern.warn kernel: [<943b8a3c>] br_handle_frame_finish+0x17c/0x1ac
Jul 16 11:02:25 fritz kern.warn kernel: [<943b8ca4>] br_handle_frame+0x238/0x26c
Jul 16 11:02:25 fritz kern.warn kernel: [<942fbe04>] netif_receive_skb+0x380/0x548
Jul 16 11:02:25 fritz kern.warn kernel: [<942fc068>] process_backlog+0x9c/0x100
Jul 16 11:02:25 fritz kern.warn kernel: [<942fc700>] net_rx_action+0xa0/0x1d0
Jul 16 11:02:25 fritz kern.warn kernel: [<94133b58>] __do_softirq+0xc4/0x18c
Jul 16 11:02:25 fritz kern.warn kernel: [<94133c68>] do_softirq+0x48/0x68
Jul 16 11:02:25 fritz kern.warn kernel: [<942fc858>] netif_rx_ni+0x28/0x38
Jul 16 11:02:25 fritz kern.warn kernel: [<942bfc2c>] tun_chr_aio_write+0x468/0x4c8
Jul 16 11:02:25 fritz kern.warn kernel: [<94192188>] do_sync_write+0xc4/0x114
Jul 16 11:02:25 fritz kern.warn kernel: [<94192868>] vfs_write+0xb0/0x15c
Jul 16 11:02:25 fritz kern.warn kernel: [<94192b48>] sys_write+0x50/0x8c
Jul 16 11:02:25 fritz kern.warn kernel: [<941026e4>] stack_done+0x20/0x3c
Jul 16 11:02:25 fritz kern.warn kernel: ---[ end trace 041304457e167f85 ]---
Jul 16 11:02:28 fritz kern.warn kernel: SKB Header too small --> proto: 8, headroom: 16, need: 46, head: 94884800, data: 94884810, tail: 948848b1, end: 948848c0, len: 161
Jul 16 11:02:28 fritz kern.warn kernel: ------------[ cut here ]------------
Jul 16 11:02:28 fritz kern.warn kernel: WARNING: at /home/hjortmann/SELL11/RELEASE_WLAN_TOOLS_ur8_build/driver/core/net80211/ieee80211_output.c:1489 ieee80211_encap_normal+0x6cc/0x103c [wlan]()
Jul 16 11:02:28 fritz kern.warn kernel: Modules linked in: wlan_scan_ap wlan_acl wlan_wep wlan_tkip wlan_ccmp wlan_xauth ath_pci ath_spectral(P) ath_rate_atheros(P) wlan ath_dfs(P) ath_hal(P) avm_ath_extensions(P) xt_tcpudp xt_MARK xt_mark xt_mac ipt_REJECT ipt_LOG ip
Jul 16 11:02:28 fritz kern.warn kernel: Call Trace:
Jul 16 11:02:28 fritz kern.warn kernel: [<94113344>] dump_stack+0x8/0x34
Jul 16 11:02:28 fritz kern.warn kernel: [<9412d97c>] warn_slowpath_common+0x84/0xb0
Jul 16 11:02:28 fritz kern.warn kernel: [<c050f2e0>] ieee80211_encap_normal+0x6cc/0x103c [wlan]
Jul 16 11:02:28 fritz kern.warn kernel: [<c050fca0>] ieee80211_encap+0x50/0x204 [wlan]
Jul 16 11:02:28 fritz kern.warn kernel: [<967553e8>] ath_tx_xmit_normal+0x58/0x4c8 [ath_pci]
Jul 16 11:02:28 fritz kern.warn kernel: [<96756a18>] owl_hardstart+0xc24/0xcc4 [ath_pci]
Jul 16 11:02:28 fritz kern.warn kernel: [<943b8ca4>] br_handle_frame+0x238/0x26c
Jul 16 11:02:28 fritz kern.warn kernel: [<942fbe04>] netif_receive_skb+0x380/0x548
Jul 16 11:02:28 fritz kern.warn kernel: [<942fc068>] process_backlog+0x9c/0x100
Jul 16 11:02:28 fritz kern.warn kernel: [<942fc700>] net_rx_action+0xa0/0x1d0
Jul 16 11:02:28 fritz kern.warn kernel: [<94133b58>] __do_softirq+0xc4/0x18c
Jul 16 11:02:28 fritz kern.warn kernel: [<94133c68>] do_softirq+0x48/0x68
Jul 16 11:02:28 fritz kern.warn kernel: [<942fc858>] netif_rx_ni+0x28/0x38
Jul 16 11:02:28 fritz kern.warn kernel: [<942bfc2c>] tun_chr_aio_write+0x468/0x4c8
Jul 16 11:02:28 fritz kern.warn kernel: [<94192188>] do_sync_write+0xc4/0x114
Jul 16 11:02:28 fritz kern.warn kernel: [<94192868>] vfs_write+0xb0/0x15c
Jul 16 11:02:28 fritz kern.warn kernel: [<94192b48>] sys_write+0x50/0x8c
Jul 16 11:02:28 fritz kern.warn kernel: [<941026e4>] stack_done+0x20/0x3c
Jul 16 11:02:28 fritz kern.warn kernel: ---[ end trace 041304457e167f88 ]---

Das ganze wiederholt sich dann noch zwei mal.
Speziell das hier

SKB Header too small --> proto: 8, headroom: 16, need: 46

hatte mein Interesse geweckt - könnte man damit ggfs. eine passende Kernel-Konfiguration auf Freetz-Seite nachstellen, sodaß das connection tracking wieder funktionieren könnte ?
Grüße,

JD.

EDIT: Nach einigen Stunde Beobachtung treten die Syslog-Einträge reproduzierbar nur bei einer bestehenden OpenVPN-Verbindung (TAP-Device) auf. Die Box läuft allerdings stets stabil weiter, ohne Reboot o.Ä.