# cat \/proc\/cpuinfo\r\nsystem type : 96348GW-10\r\nprocessor : 0\r\ncpu model : BCM6348 V0.7\r\nBogoMIPS : 255.59\r\nwait instruction : no\r\nmicrosecond timers : yes\r\ntlb_entries : 32\r\nextra interrupt vector : yes\r\nhardware watchpoint : no\r\nVCED exceptions : not available\r\nVCEI exceptions : not available\r\n<\/pre>\nAber das war es weniger, was ich wissen wollte; wenn doch es interessant zu wissen ist, dass eine CPU im Entwicklungsstadium in diesem kleinen K\u00e4stchen verbaut ist \ud83d\ude09 Wichtiger war aber vielmehr, was in der Firewall-Konfiguration verbockt wurde:<\/p>\n
# cat \/tmp\/nvram|grep fw\r\nfw_nat=1\r\nfw_block=0\r\nfw_block_keyword=\r\nfw_block_trust_enable=0\r\nfw_block_trust=\r\nfw_services_def=Any(ALL):any:1-65535Any(TCP):tcp:1-65535Any(UDP):udp:1-65535...\r\nfw_services=...\r\nfw_in_rules=...\r\nfw_out_rules=\r\nfw_dmz_enable=0\r\nfw_dmz=\r\nfw_spi=1\r\nfw_response_ping=0\r\nfw_schedule=1111111:0:0-24:0\r\nfw_time_zone=+1a\r\nfw_remote=1\r\nfw_remote_type=1\r\nfw_remote_range_start=0.0.0.0\r\nfw_remote_range_end=0.0.0.0\r\nfw_remote_single=127.0.0.1\r\nfw_remote_port=65536\r\nfw_import=0\r\n<\/pre>\nIch hab aus den Settings mal ein paar unwichtige \ud83d\ude1b Informationen entfernt. Das sind lediglich die auf meinem Router freigegebenen Dienste. Allgemein ausgedr\u00fcckt ist meine Policy Ausgehend alles offen, eingehend nur freigegebene Dienste erlaubt. Verwundert hat mich in diesem Zusammenhang die Einstellung fw_import, die man besser als „Firewall IM-Port“ lesen sollte, statt als einzelnes Wort, aber die Vermutung hatte ich sp\u00e4testens nach etwas Testen mit dem Webinterface.<\/p>\n
Interessant war nun, dass unabh\u00e4ngig von der Einstellung der Einstellung fw_import immer folgende IP-Chain auftauchte:<\/p>\n
# iptables --list REAIM_IN\r\nChain REAIM_IN (1 references)\r\ntarget prot opt source destination\r\nACCEPT tcp -- anywhere anywhere tcp dpts:1863:1864\r\nACCEPT tcp -- anywhere anywhere tcp dpt:5566\r\nACCEPT tcp -- anywhere anywhere tcp dpt:5190\r\nACCEPT tcp -- anywhere anywhere tcp dpt:4443\r\nACCEPT tcp -- anywhere anywhere tcp dpts:40000:40099\r\nACCEPT tcp -- anywhere anywhere tcp dpt:1864\r\nACCEPT tcp -- anywhere anywhere tcp dpt:5566\r\nACCEPT tcp -- anywhere anywhere tcp dpt:5190\r\nACCEPT tcp -- anywhere anywhere tcp dpt:4443\r\nACCEPT udp -- anywhere anywhere udp dpts:40000:41000\r\n<\/pre>\nwas eigentlich in Bezug auf die INPUT-Chain (DROP-Policy) hei\u00dfen m\u00fcsste, dass diese Ports explizit ge\u00f6ffnet werden – f\u00fcr alle Interfaces. Naja, wurden sie aber nicht, was ein kurzer Blick mit tracetcp<\/a> beweist:<\/p>\n# tracetcp login.icq.com:5190 -n\r\n\r\nTracing route to 64.12.200.89 on port 5190\r\nOver a maximum of 30 hops.\r\n1 Destination Reached in 1 ms. Port closed on 64.12.200.89\r\nTrace Complete.\r\n<\/pre>\nWobei selbst dieser Trace in sich bereits sehr seltsam ist, da der erste Hop mein Router und nicht der Server von AOL ist …<\/p>\n
Auch das manuelle Entfernen dieser Chain brachte keine Besserung. Also mal ein wenig bei NetGEAR auf der Seite umgeschaut und siehe da: Es gibt ein Firmware-Upgrade 1.02.15. Dieses installiert und seither dieses Problem los. Daf\u00fcr auch das Setting fw_import …<\/p>\n
Bliebe abschlie\u00dfend noch zu erw\u00e4hnen, dass die Connection jetzt funktioniert:<\/p>\n
# tracetcp login.icq.com:5190 -n\r\n\r\nTracing route to 64.12.161.185 on port 5190\r\nOver a maximum of 30 hops.\r\n1 3 ms 2 ms 2 ms 192.168.0.1\r\n2 9 ms 8 ms 9 ms 87.186.224.22\r\n3 9 ms 9 ms 9 ms 87.186.255.134\r\n4 106 ms 105 ms 106 ms 62.156.131.162\r\n5 108 ms 108 ms 108 ms 66.185.136.13\r\n6 109 ms 110 ms 108 ms 66.185.138.250\r\n7 110 ms 108 ms 108 ms 66.185.135.58\r\n8 111 ms 108 ms 109 ms 172.20.149.106\r\n9 Destination Reached in 111 ms. Connection established to 64.12.161.185\r\nTrace Complete.\r\n<\/pre>\nBis zum n\u00e4chsten Problem \ud83d\ude09<\/p>\n
![\"Flattr](\"http:\/\/blog.benny-baumann.de\/wp-content\/plugins\/flattr\/img\/flattr-badge-large.png\"){kind=icon}
<\/a><\/p>","protected":false},"excerpt":{"rendered":"