/rom/ only has the following note:
SQUASHFS USERS:
After firstboot has been run, / will be jffs2 and /rom will be squashfs
(* except when in failsafe)
And the documentation doesn't seem to be written with this situation in mind, which is quite understandable, I guess.
Having a default install and setting the PC to DHCP, connected directly by a cable should work. Perhaps the cable is bad? If you run wireshark on the PC you should see a few unsolicited packets from the router such as IPv6 RS's. If you don't see anything at all it's possible the SD card is corrupt and the Pi failed to boot.
In order to mount the rootfs on another machine and change files offline would be much easier with the ext4 build, since there the rootfs is a simple dedicated partition with an ext4 filesystem.
Once you have basic operation again, realize that the STA end of an ordinary AP-STA link such as the landlord's wifi cannot be bridged into a network. You have to make the STA the only device in a wan network and NAT/route to it. If the landlord's network is also 192.168.1.X you will have to change your LAN to something outside that range in order to route to the Internet.
2 Likes
Additionally your RPi gives you easy access to its console, either via serial or directly using keyboard/ screen, allowing you to debug the issue from both ends (which can help significantly).
Keep in mind that the wireless capabilities of the RPi are very limited and slow, just about any contemporary (even a decade old-) wireless routers/ APs can run circles around it.
Thanks, I'll try this as soon as I'm back home. I'll also test a different cable. I don't think that it's the SD Card, as I was able to mount it on another PC and access the OpenWRT Filesystem.
I'll also keep your additional advice in mind for when I solved the problem I currently have.
While being able to just connect a keyboard is certainly helpfull, I currently don't have an USB Keyboard here, though I'll probably order one for such situations.
I do understand that the whole Pi-Solution is not ideal, but as long as it allows stable internet access at all, it's good enough as a short-term solution until our fibre connection finally works.
I had that problem with my new pi4b I just got. I flashed a image using the terminal and popped in the sd card and was not able to connect to the pi no matter what. so what I did was take out the card and reflash it, this time double checking every setting. This is what I use: "sudo dd if=/path/to/openwrt-21.02.0-bcm27xx-bcm2711-rpi-4-squashfs-factory.img of=/dev/sdc bs=2M status=progress" That's a literal copy-paste from my terminal's memory of an actual flash process that actually works. Well yes I did change the /path/to/xxx part for relevance LoL. Give it a try if you still can't connect, nothing to lose right? Replace sdc with whatever your sd card is. It took me 2 flashed to get it right but she now works great. BTW I wset up my pi without using a usb keyboard mouse or a micro hdmi adapter. Did it all over the ethernet ala headless. You can do this you just got to figure out what's going wrong.
BTW the others are right, the pi's WiFi is a 802.11 b-g-n-ac 1tx1r with only 1 antenna WiFi chip so its low speed low power and BTW the pi4b has a not so great antenna as well.
Do you have ANY old router even an 802.11N and possibly a G model you could use as a wired access point or a wireless repeater? Almost any old router would probably be much much better for what you are trying to do.
I'll try that and report back.
I've got an old Zyxel vmg3925-b10c lying arround, but I dont think that I can use that to join their WiFi as a client. Laying an ethernet cable from their house to ours just isn't practical.
This also isn't supposed to be a long term solution, just a quick and dirty "hotpatch" to bridge the time until we finally have our own internet access back. The Pi get's about 30-40 mbps at that spot in that network, which is enough for my classes.
I find cat a better experience for flashing images to cards.
cat /where/the/image.is > /dev/sdX && sync
1 Like
Yes make sure to run sync before unplugging the card or you may have an incomplete write.
I could be wrong but typically sd card readers do not need sync because they do not typically employ write caching. Or at the very least, I've never been able to get one to enable it. hdparm always tells me no, So sync would be redundant yes? I mean we are talking about a sd card here.
Edit: after more reading apparently sd card readers do exist that can have onboard cache just like a hard drive. Wow learn something new every day and yea I guess I have to concede that sync should be used after all.
I've made progress, I guess.
When flashing the card with cat /where/the/image.is > /dev/sdX && sync , I still get the same Connection Refused Errors. When flashing it with sudo dd if=/where/the/image.is of=/dev/sdX bs=2M status=progress && sync , I get an Adress Unreachable Error and even pinging 192.168.1.1 fails.
From this, I gather that the flashing with my original parameters, as well as with cat did work, and that there is another Problem somewhere. I am however, quite onsure on how I'd diagnose it.
Sorry for the relatively late replies, I had a rather busy week up until now.
Edit: The original, succesfull Install was made with an image flashed in Rufus, so I guess I'll also try that again.
Are you uncompressing the image first? The file on the download server is a gzip (.gz) which must be uncompressed before flashing. The command below pipelines the unzipped output into dd.
gzip -cd VERSION-rpi-4-squashfs-factory.img.gz | dd of=/dev/sdX bs=2M
or (advanced usage) you can pipeline from wget direct from the server through gzip then to your card:
wget -O - https://IMAGEURL | gzip -cd | dd of=/dev/sdX bs=2M
which handles .gz files if I recall - I think
may be the answer!!
personally, I use
zcat openwrt-21.02.0-bcm27xx-bcm2711-rpi-4-squashfs-factory.img.gz | dd of=/dev/sdX bs=4M
but that's just another way to skin the same cat
Perhaps I should have point out in my previous reply that the X represents "unknown: you fill this in". I do not know which drive your card reader resides on. Use fdisk -l or lsblk to find where the card reader is and its correct drive letter to use. It could be either /dev/sdb or /dev/sdc. BE CAREFUL. With a wrong drive letter (usually sda), you can wipe out a drive you wish to keep.
Same thing for /where/the/image.is. That's not the actual location of an image to use. You're supposed to fill in the blanks here too.
I apologies if this is a basic knowledge you already have. I'm just covering all bases here since you've reported continued failures with dd and cat.
Say for example your sd card is /dev/sdc1 when you do the flashing command, however it is done, you are suppose to point it to for example /dev/sdc and NOT /dev/sdc1. I have made that mistake more then a few times. Perhaps you are as well? And olav is spot on make sure you have the right drive letter or you are hitting the wrong nail over and over. And don't assume it is always the same letter for the same drive, sometimes it will change depending on what is plugged into where and what was plugged in during startup.
Other then that check and or swap sd cards if you can. Maybe the card worn out or defective.
Short update - during the last two weeks, I sadly didn't have time to try any new solutions due to being quite busy with uni and work.
I don't think that the SD Card is the Problem, as the Pi boots fine when I flash the Card with Raspian. I did, in fact, use the proper paths in the Command.
Luckily, our fibre has finally been properly connected and everything is working, though I'll be happy to return to OpenWRT in future, though probably with a proper Router.
1 Like