Warum funktioniert es nicht mit der FritzBox 7490 bzw Synology Cloud Station?

Mike Burkhardt shared this question 2 years ago
Need Answer

Ich bekomme es bei meiner FritzBox einfach nicht zu Laufen. In Safari überhaupt nicht... In Firefox geht es zeitweise. Meine Synology Cloud Station funktioniert nach der Einrichtung auch nicht mehr. Ich habe es mit der manuellen Einrichtung versucht. Als Gateway habe ich bei den Clients die IP meines Rasperry Pis, auf dem das Ganze läuft, eingetragen. Ich weiß, dass der Fehler mit der FritzBox ist bereits bekannt.


Wird das voraussichtlich gefixt?

Ist es außerdem wichtig als DNS Server die Adresse des Router anzugeben? Ist dies für die Funktion unbedingt notwendig?


Ich habe bisher versucht die Fritzbox als DNS Server auszuschließen, da es da Performance Probleme gibt.

Best Answer
photo

We have published 0.8.3 which should fix the issues with manual network configuration.

Comments (49)

photo
1

There are several questions here:


  1. Why does eBlocker not work on a FritzBox 7490?
  2. Will the problems with FritzBox 7490 be fixed?
  3. Why does Synology Cloud Station not work?
  4. Is it necessary to set the router's IP as DNS server in eBlocker's manual network configuration?


I will try to answer:

  1. When a device is on the FritBox 7490's WiFi, we have observed that packets are routed back and forth between the FritzBox and the eBlocker, if the destination port is not 80. So for example, traffic for SSL, FTP, etc. can not reach the internet. HTTP traffic should work, however. Devices on the FritzBox's LAN should not be affected.
  2. We are still trying to find a solution for this problem.
  3. We have not observed this yet with our Synology. We recommend to whitelist the device in eBlocker's settings. Can you provide more information about what does not work?
  4. In manual network configuration you can configure any DNS server(s), it does not have to be the router's address.

photo
1

Thank your for your answer... I'll leave an english reply this time so everybody can understand whats going on..


2. I Hope you are going to find a solution since the 7490 is a wide spread model in Germany

3. Sorry, i meant the Synology Cloud Drive App on Mac Os X. It uses SSL so thats probably why it doesnt't work. All my clients in my network are connected over WiFi.


Please let us know when you find a solution for the 7490 problem.


Other than that... good work so far... thumbs up! I do like products a lot Made in Germany...

photo
1

Do you have a workaround for the 7490 problem?

photo
1

There is no workaround yet, unfortunately. We have reduced the problem to a very simple setup and are in contact with AVM to resolve the issue.

photo
1

UPDATE:

The bug isn't fully fixed yet. We're in contact with AVM and will keep you up to date.

-----------------------

AVM (manufacturer of FritzBox) has confirmed their bug. The fix can be downloaded as a beta version here. The final version is due this autum according to AVM.

photo
1

Hallo nach Hambug;

ist diese Update auch für die 6390 (Baugleich aber für Kabel Unitym. )gedacht?

Wenn nicht,was ist dann die Lösung??

VG

Dietmar

photo
1

The problem is a bug in AVMs firmware and the issue is not caused by eBlocker. Please check back with AVM as we can not give support for their devices. Sorry.

photo
photo
1

Thank you very much! Everything I tested (Email, FTPS etc.) seems to be working now (FB 7490+2,4Ghz Wlan+Repeater E300 and (FB 7490) 1Gbit LAN+Timecapsule (5Ghz Wlan)+ 3 Airport Express).

photo
1

...I was too hasty. Still hickups in the FB-2,4Ghz WLan.

photo
1

Can you please more specific what the "hickups" are so we can send them to AVM.

photo
1

Sometimes it was impossible to connect to the 7490-vpn oder the 7490-ftps-server and also ftps-client-connections and email (ssl)-connections were impossible. I am sorry, but I did not have the time to find the cause for the various connection problems. I simply turned the 7490-wireless off and disconnected the fritz-repeater and switched to the wireless from the timecapsule (connected via 1gbit-lan to the fritzbox). Since then, everything seem to run smoothly with automatic setup, even with 3 airport express boxes now used as repeaters and airplay clients...

photo
1

One addition: Though everything seemed to run smoothly the last couple of days - tested mainly with browsing and VPN and ftps-connections- , today I experienced problems with downloads of large files, which failed because of (non-obvious) disconnections. All downloads via Safari from different Servers (e.g. steinberg.de) and the Apple App-Store failed after a few seconds. I had to exclude the devices I wanted to download with in the eblocker-settings...

photo
photo
1

FYI: Even with very latest FW (FRITZ!OS:113.06.36-31822 BETA) the issue is still unresolved: HTTPS or FTP sites simply do not open. So eblocker is unusable as (default) gateway.

F!B 7490, clients connected via WLAN, eBlocker connecter via LAN or WLAN (wireless bridge).

eblocker 0.8.0.

photo
1

Hi all,

my eBlocker unfortunately doesn't work, neither with FritzOS 113.06.36-31855 BETA nor with 2,4 GHz WLAN (and 5 GHz deactivated). Websites with SSL don't load at all, the mail app can't establish a stable (SSL-) connection to the IMAP-server and most of other websites don't load as well or it takes minutes. With cable connections there is no problem. Because we only use Wi-Fi-computer (and other mobile devices) I switched off eBlocker (0.8.2).

photo
2

Hi, same problem with the Fritzbox 3490 (basically same as FB 7490, but without the phone module). Very sad, that eBlocker is unusable with Fritzboxes. I thought I could benefit from being an early tester and supporter, but PI is just a brick here. Do you plan to extend the free updates for the early supporter until this bug is resolved ?

Thanks.

photo
1

Just my two cents: Isn´t this always the case with pre-beta-testers that you run into problems which can be ironed out during the further development of a product? Usually it should not be the beta-tester who benefits from testing the product, but the product itslef. If you really want to try eBlocker, why don´t you get a 20,00€ Wifi-Amplifier/Repeater, connect it to the Fritzbox via Lan Cable and switch off the Fritzbox Wireless? eBlocker is running very stable here with a Fritzbox 7490. You just need a cheap little box to do the wireless network part....

photo
1

@Malte: "Early Access" (pre 0.8) was pre-BETA.

Since 0.8 we can consider this at least a public BETA (est. delivery of eBlocker Box: November 2015, a.k.a. now).

Well, except eBlocker is Bananaware* where even the official release is pre-BETA. :(

* https://de.wikipedia.org/wiki/Betatest:

"In der Softwarebranche ist es in den letzten Jahren üblich geworden, Software in einer öffentlichen Betatestphase (kostenlos) an Endkunden herauszugeben, um Stabilität und Fehlerfreiheit möglichst preiswert zu testen. In diesem Zusammenhang findet man häufig den Begriff der Bananenware („reift beim Kunden“). Hierbei wird von Kunden unterstellt, dass ein Produkt, das sie als mangelhaft empfinden, eigentlich noch in der Betaphase sei, obwohl es schon verkauft wird."


P.S. 1W permanent power consumption equals ~3 EUR p.a. Cheap devices often use >>10W so your workaround is way more expensive than you think.

photo
1

Ok, we both agree, it is still beta...


All I wanted was to make clear that if one wants to participate in a Betatest, one should not expect a final and complete product. And even more important: In this particular case, the problems seem to be caused by a faulty software of the fritzboxes... So, if this is true, one should just get an appropriate setup to test eBlocker and help to improve it instead of blaming the wrong guys.


P.S.: You do not need to use the "costly" workaround. You do not need to test eBlocker at all - you could just wait for the release of V1.0 and lean back and relax. ;)

photo
1

Great to get to know eblockers lawyer :)

But you're, once again, wrong. In any serious development process the BETA equals the RTM version - functionality, features and GUI are fixed and the whole purpose of the BETA is a broader testing in way more diversified envirnonments than in ALPHA and pre-BETA.

So, yes, (if one considers the developer a serious company) one has to expect "a final and complete product" (as you name it).

It may contain a few strange bugs (to find and fix these is the purpose of BETA phase). Seriously ALPHA- and pre-BETA tested products should work in the most common environments though (AVM estimates to have sold over 1 million 7490 boxes!).

photo
1

Just to end this discussion with two simple facts:


1. Neither am I "eblockers lawyer" nor do I have any business interests in this company or product. I am only beta-testing a product I find quite interesting.

2. The only person who is wrong is you, assuming that a Beta-Version (by definition (?)) always "equals the RTM version-funcionality, features and GUI". You could have known better by reading the eBlocker-release notes.

photo
1

1) you act like one

2) pls. don't talk about things you don't know the basics of. Just ask any senior software engineer or PM how a development process is structured and what BETA phase means.

photo
1

You are neither getting the point, nor sticking to the facts, so please stop speculating. Maybe you would like to see your definition of "BETA phase" being mandatory, but in actual fact, it is not. Just ask me next time. ;)

photo
1

Sticking to proven standards is what differs professionals from dabblers.

BTW: Ths case (thread) is a proof of above sentence.

photo
photo
1

@eBlocker: Why don't you get Freetz on a 7494 and use SSH root access to find the issue yourself?

See the routing table of the F!B, do tcpdumps on the device itself and analyze them (even easier: compare them to the same data of a working box and find the differences).

You pretend to be networking professionals so it should be an easy and quick way to solve this issue that makes you independent at all of AVM (if you find a workaround) or at least helps AVM to solve the issue quickly (if a FW fix is needed).


Regards, F.R.

photo
1

Update:

For more information about the F!B 7490 Bug, please take a look at our knowlegde base article.

photo
1

Regarding that KB article:

"The FritzBox 7490 has a confirmed bug" -> bloody lie, the 7494 is just fine. eBlocker is producing duplicate IPs in 7494s ARP table.

"This bug is not eBlocker specific but is the result of a non standard routing when using WLAN in the particular 7490" -> true, it doesn't matter if you use a screwdiver or a wrench to shortcut (sabotage) a circuit.

"(AVM) is aware of the bug." I'll make them aware by tomorrow that it's not a bug.

"While HTTP connections work fine" -> no wonder as eBlocker does not route HTTP traffic but proxy it (fun fact: same appearance to the router as SNAT produces)

"If another WLAN access point is connected to the FritzBox 7490's LAN, the problem does not occur." -> sure, that's equal to connecting the device directly to that LAN port of F!B.

"The problem is not related to the eBlocker software." -> true. The problem actually is not the eBlocker software but the engineers implementing the wrong software for the job.

"It can be reproduced by" -> sure, it doesn't matter what device/software is wrongly used. A Porsche 911 cannot plow an acre but that's not Porsches fault. Proof: A VW Passat can't either.

"ICMP packets are routed without any problems." -> bloody lie! As any packet sniffer will show you the ICMP packets are replied to by [TTL exceeded] (ICMP type 11) too. The traceroute software you used is just not sophisticated enough to tell (you) the difference and is OK with any packet it received in response.

Get your facts straight, pls! It's not a bug in a software/device if it does not tolerate standards violating behavior of rough devices. It's rather a weakness of the other devices who tolerate such.

Regards, F.R.

P.S. There will be other devices (cheap plastic routers excepted) coming up that will have/use the same hardened networking. If you only fix the symptoms (press AVM to 'fix' their product) you(r users) will have the same issue again and again. So fix the cause and not the symptoms.

photo
photo
1

@Tim/eBlocker: I took some time today to analyze the issue for you.

The solution: use SNAT instead of 'routing' internally and all is working.

Any hardened networking OS (or a better switch /w MAC lock per port) will block violations of network standards.

And just in case you ask: NO it's not a deliverable of any modern OS to support duplicate IP or MAC addresses, especially on different network ports (in case of the F!B issue on eth and wlan). But what you do by sending packets with the source IP of the WLAN-client and the source MAC of eBlocker to the router (e.g. within the same subnet) is creating duplicate IP addresses (different MAC addresses assigned to the same IP address in at least the routers ARP tables).

I'll contact AVM tomorrow to ask them not to weaken their OS to support a company using hacker techniques (like the ARP poisoning you use in AUTO mode) or violating network standards (fun fact: unique addresses are the base of any communication!).

Regards, F.R.

P.S. To say it clear: This issue is not a bug at AVM but a violation of networking standards by eBlocker! One MUST NOT 'route' within the same network segment (subnet).

photo
1

Thank you for the suggestion. We will evaluate if SNAT fixes the issue.

photo
photo
1

We have published 0.8.3 which should fix the issues with manual network configuration.

photo
1

It only fixes the 'dead connection' issue!

It's only a workaround as you still (well, now even more than before!) endanger the privacy of eBlocker users.

Connections to tcp/80 are routed through Tor (if 'anonymity' is enabled), all others directly using the users direct/native internet connection (and assigned IP).

Guess how much effort it is to connect these two sessions, get the 'real IP' of an eBlocker user :( :(

I told you a solution for the connectivity issue (glad that AVM did not give in!!). A serious (in matters of privacy) solution was a (transparent) proxy though, tunneling all traffic through Tor (as soon as 'anonymity' is enabled).

photo
photo
1

My eBlocker still doesn't work correctely via WLAN. The connections are very, very slow, SSL-sites interrupt usually with time out. eBlocker 1.8.3 / WLAN 5 Ghz / 7490 with 06.50

Do you think you will come up with a solution that works 100% or it's a "workaround" for longer time?

photo
1

Hi Daniel,

have you activated the manual setup? This is absolutely necessary.

Best regards

photo
1

Hi Tim,


no, I haven't. Why? It's part of the workaround or the final way?


I'm not a network expert, but I can't activate manual setup in my view, because I have a NAS with fixed internal IP and port forwarding for a rsync backup job of an external server. If I don't want to configurate all devices manually and activate the FritzBox to "broadcast" the new DHCP server on eBlocker, the rsync connection faile. Right?


Best regards

Daniel

photo
1

You can select manual setup but not have the eBlocker handle dhcp - you can switch the eBlocker dhcp server off on the manual setup page, and have your own server handle it - you just need to make sure that your own dhcp server passes the eBlocker IP address as the default gateway when it hands out leases

photo
1

Thank you Andy for the help! Sounds good. ;-) But how can I make sure the DHCP server of the FritzFox passes the eBlocker IP as default gateway? Which setting in which menu I have to set? @Tim: You have a Fritzbox in the office, could you help?

photo
1

I don't know the details of the fritzbox specifically, but on my asus (and most other decent routers), where you configure the dhcp server for ip range etc, you can also set the IP address of the default gateway that it hands out in the lease.

photo
1

@Daniel:

AFAIR Fritz!OS doesn't provide that option.

Easiest was to manually configure your devices IP address (just google for a HowTo in your language and for your OS).

IP and netmask from your LAN (if you didn't change your F!Bs default settings: 192.168.178.x, netmask 255.255.255.0), eBlockers IP as default gateway and F!B as DNS (again: default was 192.168.178.1) and you're good to go.

photo
1

@Tim: Are there any news about this topic and solving the problem? I've eBlocker beside our FritzBox and it's switched off for six weeks because I don't want to configure all devices manually or work with network sets for home and office usage. That's cumbersome and time-killing. I looking forward the "zero installation" feature. Or do I an update?

photo
1

Enabling DHCP on the eBlocker and disabling it on the Fritzbox should not interfere with the static IP address of your NAS. So the port forwarding from Fritzbox to your NAS should still work. Have you tried manual network configuration (with DHCP enabled) on your eBlocker?

photo
1

No, I have not tried this way. Because the NAS gets the IP via DHCP and the Fritzbox-function "use the same IP for this device" and I've not enough know-how and time to try and error with the configuration of network and/or all devices and check the nightly backup via port forwarding to the NAS. I don't go for it honestly. Yes, it's an indigogo project and still developing. But on the other hand I bought a device for 300$ with promise "zero installation". So I expect plug & play...

photo
1

Hi Daniel,

we are sorry, but the only possibility is giving a static ip address to the NAS.


Best regards

photo
1

Daniel,

in case you have ever been to the WebUI of your NAS you can just set there a fixed IP (the same you told the F!B to reserve). Leave the F!B untouched but set the NAS IP manually and you should be good (make sure your NAS has the F!B as Gateway, not the eBlocker!).

photo
photo
1

My eBlocker stopped working (with 0.82 and 0.83). Probably it hast something to do with the Fritzbox 6.50 Update, but I did not have the time to look into it. I switched to manual setup, but I still have connection-timeouts and sometimes the connection seems to be completely broken. The eBlocker-Icon disapeared, though I always can access the eBlocker backend via the ip...

photo
1

Hi Malte,

have you activated DHCP on the eBlocker device AND deactived DHCP on your router?

Best regards

photo
1

Hi Tim,

yes, DHCP is activated on the eBlocker and deactivated on the Fritzbox,

thank you and best regards!

photo
1

Hi Malte,

and it does not work anyway? Do you have more devices like switches in your network?

Best regards

photo
1

Hi Malte,

and it does not work anyway? Do you have more devices like switches in your network?

Best regards

photo
photo
1

I've updated my FritzBox 7490 to 6.50 a few minutes ago and the eBlocker is running 0.83. I'm additionally using a Fritz WLAN Repater 450E. All of my WLAN-devices were disabled in the past because of poor or no connections when the devices were activated in eBlocker settings.

After todays update to 6.50 I gave the WLAN another try and my first device (iPad) seems to have a normal connections through eBlocker now. :-)

I'm using the proposed manual setup with DHCP-Service of eBlocker. I'll activate my iPhone too and wil check a few days before activating other WLAN devices.

photo
1

I've setup the eBlocker with version 0.8.1 at my Fritz!Box 7490 (OS 06.51). Going on eBlocker settings, switcht of 'automatic' under network and DHCP off. Also I activated autoupdate and my eBlocker gets the 0.8.9-2 (beta) version.

Until now I don`t check much but for me it seems all ok. This text I wrote on my notebook via WLAN and also internet connections from my smartphone via WLAN is working.

The next days my family and I will testing more different usecases :-)