Fritzbox 7330

[Cherish Asleson]

Hito all,

I have an old Fritzbox 7330 Italian edition (the red and gray one with Article no: 2000 2590 and SAP no: 5013 written under it, so different from the black SL version I suppose in term of hardware and firmware) and I would like to install OpenWRT on it so that to have a wireguard or IPsec VPN client and be able to share the VPN using the router for all the devices I have in my house.

Is it possible to do that with OpenWRT? Is my device supported?

In case it is possible is there any clear guide on how to install OpenWRT on this device?

You'll need to get a device that is supported -- you can use the ToH to select an appropriate device, or you can look to see what is available (used or new) and then refer to the table to confirm support.

I'm newbie and trying to learn about OpenWrt-project. First I want to test OpenWrt on my old router (AVM FRITZ!Box 7330), which I do not use anymore. The page says that it supports version 19.07.1, but I can't find any install image on it. Only OpenWrt Upgrade.

Which image should I install first?

I had a working setup of OpenWrt with FritzBox 7330. Unfortunately while trying to setup the ISP, I changed the IP Config of the LAN/WAN port from Static (which gave a gateway IP of 192.168.1.1) to Dynamic/DHCP.

Basically I need to reset the IP Config of the gateway, but I dont know how I can do that. Is there a way to reset the firmware ? I don't see a reset button and don't know how I can hardware reset the OpenWrt firmware.

Moreover I am only requested the ssh password when I setup static IPs (192.168.1.1) for the gateway. Otherwise when I check my OS network settings, I get a self assigned IP of 169.254.X.X. Is this correct ?

In most cases, when performing Fritzbox modifications like installing OpenWRT or gaining root access on the Linux system, the 4-pin UART interface suffices. However, if you encounter broken or bricked devices and require flash memory dumps, having access to the JTAG interface can be immensely helpful.

When encountering an unfamiliar circuit board, the initial step is to search for familiar pin headers or debugging markings, typically positioned near microprocessors or microcontrollers. Although I regret not having taken an overall picture of the FRITZ!Box 7330 board before soldering jumper wires onto it, I believe the concept is clear.

At our workplace, we rely on the Inter-Tech KVM IP-KVM101, a compact and versatile KVM over IP switch that, when combined with 16-port KVM switches, grants us complete control over a rack with test hardware.

I decided to order a slightly less powerful model, the Sunon DP201A, from Reichelt Elektronik as a replacement. While both models appear similar at first glance, I noticed a significant difference: their connectors are entirely different. This discrepancy has led me to question whether the original fan, the DP200A, was genuine. Could it have been a counterfeit?

I want to start by emphasizing that this method of reading ROM chips is potentially destructive. The process of desoldering and possibly resoldering the memory chip carries a risk of failure. I tested this on two Sharp CE-150 PCBs I had designated as spare parts. This is more of a proof of concept, as there are simpler, non-destructive methods for ROM extraction on a Sharp PC. However, driven by curiosity, I decided to share my experience.

Initially, I had no intention of desoldering the ROMs. My first approach involved using probes attached to the individual pins of the chip to read the content of the Sharp PC/CE ROM chips. However, this proved unfeasible due to the narrow leg distance of the QFP chips (0.8 mm).

Breakout boards are useful for accessing the individual pins of the QFP chip. I experimented with two methods of positioning the pin headers on the board: on the top and on the bottom side. Each method has its advantages and disadvantages. Placing the pin headers on top provides easy access to the pins, but tracing connections from a ROM chip leg to a pin can be challenging without detailed notes. With the pin headers on the bottom, I constantly had to flip the board over. For ease, I recommend keeping an unused breakout board for reference and placing pin headers on the top side.

Finally, I achieved success by using real ATMega 8-bit ports instead of the confusing Arduino pin numbers and maintaining strict timing. The resulting dump was identical to one I generated earlier. At least that brought some satisfaction!

For the purpose of testing, I used the original circuit design and simulated it in LTspice, which I ran under Linux with Wine. LTspice is a versatile tool for simulating both analog and digital circuits, making it ideal for my experiment.

In this post, I describe a method commonly used to dump RAM and ROM images on Sharp PC-1500 and PC-1600 systems. This non-destructive method is applicable to most Sharp PC ROMs and extension cards. It requires only a Sharp CE-150 extension, an audio cable, and a computer with a microphone input (e.g., a sound card).

The CE-150 Color Graphic Printer, besides being a plotter, offers two audio interfaces (line-in and microphone output). Historically, these were used to transfer code or data between Sharp PCs and tape recorders. While such recorders are mostly outdated, this method remains effective with modern sound cards. There are free software tools available (like pocket-tools) that convert recorded audio files into binary dumps, and even into BASIC code.

By default, memory from the 64k ME0 area will be dumped. Remember that different areas are addressable depending on the ME0, ME1, PU, and PV flip-flop settings. CSAVE can directly address only the ME0 area, to my knowledge. However, you can copy content from one range to another using PEEK/POKE [#], iterating over two memory ranges, and then dump it. This approach has worked for me before I had more advanced machine language tools.

Initially, I had no idea what it was. My first thought was that it could serve as a nice case for another project I was working on. However, curiosity led me to do some research, and I found the device intriguing enough to photograph its interior and write about it.

The speaker features an internal lithium-ion battery for portable use. I suspected that the battery had slowly discharged while in storage, triggering the undervoltage protection. This mechanism typically prevents defective cells from charging. In my situation, I was hoping the cell was still viable and could be revived with a jump-start, a technique that was successfully used in other instances.

Somehow it feels wrong to call this the low-end model in the Fritz!Box 7300 range, but that's what the 7330 is - low end. It's a harsh description for a piece of communication hardware this able, but it earns it due to its relative lack of features compared to its bigger brothers such as the FRITZ!Box 7360.

The best way to describe the Fritz!Box 7330 is as a communication hub - this is no lowly network router. Its abilities stretch to being an entry-level PBX or Private Branch Exchange to you, making this a SOHO-class bit of kit.

Alongside the usual ADSL2+ modem, the 2.4GHz 300Mbps wireless and the highly versatile switch - oddly with a single Gigabit and 100BaseT LAN port - is a host of analogue, DECT, VoIP and mobile phone capabilities. You can add up to six compatible DECT phones, divert calls to mobile phones via an Android or iOS app and take calls for up to five numbers from the built-in answer machine. It's a crazy configuration that's ideal for any small office.

If you're in the market for a box that can handle your DECT phones, re-route calls, offer answer-phone capabilities, automatically route VoIP calls from smartphones, deal with faxes, provide an ADSL2+ modem and be a 2.4GHz router then you're either a very busy person or an entire office. It has the same features as the rest of the 7330 range, apart from the UK-limited VDSL broadband technology.

The one area AVM seems keen to cut away are the LAN ports with just two on offer and one being 100BaseT, the other is Gigabit. It's an odd mix and on a 100+ unit somewhat annoying as it could be a deal breaker for many.

One area that isn't skimped over is the interface and installation, with the usual comprehensive and fast web interface ever present. It's potentially complex for the novice, but the Expert mode pleases our desire for comprehensive settings and information.

We were intrigued to see if AVM had cut corners on the wireless abilities and in a way offering only 300Mbps 2.4GHz WLAN seems to do just that, but under testing it was among the fastest models we've used.

Rounding things off is IPv6 routing, basic scheduling and parental controls. The lack of 450Mbps or 5GHz wireless could put off those who want the bleeding edge, but there's little support for those technologies right now.

Note that the information above is merged from all current Firmware versions available for this model, if there are multiples.

For a more detailed per Firmware view see the Firmware-Scans below, and have a look at the Firmware-History.

Daily updated index of all FRITZ!Box 7330 SL firmware modding projects. Last update: 2024-07-27 09:51 GMT.

This list excludes community ripping, code raping, project killing and permanent quarrel and combat enforcing individuals.

BoxMatrix tries to be a service to the community without doing harm to anyone, and not a platform to advertize the opposite.

Mother nature will bill for all time, manpower, projects, fun and passion which was ripped from the community for sick battle.

Let this reaver suck all honest work on this planet and pretend he knew it first. Mother nature will ripp it off his bones.

And if this sick (single sided) perversion continues I have no other option than invoking the police. Please someone stop him.

Daily updated index of all scanned FRITZ!Box 7330 SL tarballs, most of which are online. Last update: 2024-07-27 05:08 GMT.

The (main/scrpn/boot/arm/prx/atom) label in the Model column shows which CPU is meant for models with multiple Linux instances.

The Ver column shows the Firmware-Version derived from the tarball's filename, or 00.00 if not detectable.

There's no way to find this number in the source. Click the version number to get a listing of the entire tarball.

The Kern column shows the Kernel-Version from the kernel Makefile, click it to get a listing of the kernel source.

The BB column shows the BusyBox-Version from various scan sources, click it for listing the busybox addons.

The Libc and LcVer columns show the Libc-Library and its version where it could be detected, which is complicated, no listings yet.

The CC column shows the GCC-Version from its root Makefile, click it for a listing of the gcc source in the tarball.

The BR column shows the Buildroot-Version if detectable, click it for a listing of its source in the GCC tarball.

The Date column shows the date of the newest contained file. By default this list is reverse sorted by this date.

This is no perfect method, since AVM sometimes repackages older tarballs. No better method has been found so far.

3a8082e126