TD-W8970 v1 crash with no visible errors in logs

This is rather strange for me TBH but still I dont think if it's possible. Even if it was possible, you'll need to create VLANs and you'll probably need to create different networks that can be connected to those VLANs but still you can't assign same subnet to different VLANs (AFAIK) and if you assign a static IP to a network that IP will be considered a gateway for the connecting device to that port and device will need an IP address different to that IP but in the same subnet.

This is possible and you just need to go to LAN physical tab and untick the bridge option and then assign a eth0 interface. Create a new interface and do the same with wlan.

Basically no, the switches in a typical all-in-one router work on Layer 2, Ethernet addresses, not IP addresses.

You could subnet down to a /30 so each subnet has an IP for the router, one for a device, and a broadcast address, but that's going to be a maintenance nightmare, as well as destroying any on-link services.

I'm not sure what you're trying to accomplish with that topology. Perhaps explaining your goals would lead to an approach.

Sorry to continue to write on this forum. Btw how can I build my image to be as verbose as possible? I want to know if my image is crashing for reason or is the CPU simply giving up.

Is this an equal error pattern ?

Might be? But I do not use asterisk... Anyway this log-less crashes are extremely annoying.

It has nothing to do with asterisk it self.
It happen when i try to change the owner or rights of large files that are exist from beginning.
Can look in /urs/lib and try to change the rights from bigger files. ?
(try chmod 0777 and change back chmod 0755 )

Define "bigger files"

ls -al /lib/firmware/xcpe_581816_580B11.bin
-rw-r--r--    1 root     root        898952 Mar  9 15:10 /lib/firmware/xcpe_581816_580B11.bin
chmod 0755 /lib/firmware/xcpe_581816_580B11.bin


ls -al /usr/lib/
-rw-r--r--    1 root     root       1799939 Mar  9 15:10 /usr/lib/
chmod /usr/lib/

I think it may be related to flash being the source of the problem and if it is the case and flash causes the crash then it's also possible that there may not be any logs since there would be nothing in the system to produce the log.

I just finished an "internal HDD" mod on my router (basically I removed the usb ports, soldered a new one facing inside the router and put a new tiny 4GB usb inside it, with two partitions 2GiB Etx4 and 1,5 GiB SWAP, remaining space left unpartitioned)... Is there a way to offload as much things as possible to USB? Now I only use it for saving logs (so I do not lose them on crashes) and to save crashdumps.

OK. I'm at work now I'll try it as soon I go home (in ~6h).

"Extroot" mounts a "normal" file system as an overlay on top of the typical JFFS-over-ROM system. If you copy "everything" to the top-layer file system, I would think it wouldn't use the flash-based ROM and overlay except at boot, before the second overlay is mounted.

Did git bisect ever lead you to an idea of what might have changed since early v17?

Planned to do that. RIght now I have too much load form work and university but I'll do it.

Also... Can I run openwrt from USB? Completely from USB? Like flashing a bootloader to the flashchip that does nothing excpet loadinh what inside the first partition it found?

May you elaborate that more? I have a 8MB flashchip and since I also mostly use minimal builds I've never tuched extroot (I even used to remove that feature completely while testing ultra-minimal builds).

"USB" overlay -- if it's here, it reads/writes to this layer, if not, look at the next layer down

Flash-based overlay -- if it's here, it reads this layer, if not, look at the next layer down

Flashed-based ROM -- If it's not here, it's not anywhere

"Deletes" are done by putting a special "mark" on the overlay that effectively says "don't look behind the curtain, this file is gone".

So by copying everything (except /var/ /tmp/) to the top-most layer, the lower layers no longer get accessed.

How xD? I do not thing that I can do mv stuffs /dev/top_layer/ xD

I'd either use tar or rsync of with "exclude" rules for the memory-backed and "special" file systems (like /proc/, /dev/, /sys/) and the mount point, or perhaps cp -rp on /rom/ and /overlay/upper/

I built a new image with a custom /etc/config/fstab that automatically mount as overlay the partition with owrt_overlay as label... and it works :3! Now I have a nice image that even at its first boot do not touch (or at least not so much) the flashchip for writing. Now to avoid even more stuffs I should copy things from /rom/ to /overlay/upper/...

To do it properly without overwriting stuffs that should not be overwritten, my idea is:

  • Get a list of all custom files I modified after the first boot
  • Files modified / created / automatically by OpenWRT are already inside /overlay/upper/ (and thus in the USB)
  • Open the sysupgrade image I built like an archive to get a full list of real/non-special/non-memory-backed files existing in the ROM
  • Merge the lists to get an files to exclude/include lists
  • Manually copy everything

Or there is a fancy (more intelligent) way to do it? Can I do something like dir / -R (print all directory and subdirs starting from /) but excluding special stuffs?

I'm dumb. looking at /rom/ (and coping from it) make much more sense u.u i should just copy form rom to upper overlay without overwriting already existing files

I ended up using cp -aRu /rom/* /overlay/upper/... it still works :smiley: what you think? Are there better ways to do it?

Btw that + customized fstab built-in the image to autoload the overlay even at first boot, now my openwrt image runs 99% of the time from USB. Be careful guys if you follow my exemple, to properly reset your router you have to format (from a pc) the overlay partition BEFORE turning up your router (possibly in failsafe mode) to perform a firstboot command and reset your configuration.

I'm not a big fan of writing directly to the parts of the overlay system. Too much magic going on for me to trust that I've gotten the state properly updated. Mounting it as an overlay (over nothing) would probably be more robust. See Script: Mount "Alternate" NAND Firmware (Linksys +?) for one sketch of how to mount an overlay-intended file system and then apply it as an overlay (over an empty "lower", if you want "everything" copied). (I'm not sure you're writing to an overlay-intended file system. Reading from one that is not mounted as an overlay (and was cleanly unmounted) should be OK to extract the changes.)

"Better"? Probably something like building a kernel and system that runs natively off the USB file system. Worth the time on a TD-W8970? Personal decision.