What's the easiest way to migrate from Pi4 to Pi5?
In this case I've a Pi4 running from a USB mechanical
hard disk. What I'd like to do is upgrade the existing
system OS to boot either Pi4 or Pi5, but I'm wary of
unintended consequences. The disk is fairly new and so
far has been reliable, so there's no strong incentive
to replace it.
Thanks for reading, and any suggestions.
What's the easiest way to migrate from Pi4 to Pi5?
In this case I've a Pi4 running from a USB mechanical
hard disk. What I'd like to do is upgrade the existing
system OS to boot either Pi4 or Pi5, but I'm wary of
unintended consequences. The disk is fairly new and so
far has been reliable, so there's no strong incentive
to replace it.
Thanks for reading, and any suggestions.
bob prohaska
On 05/06/2024 17:07, bp@www.zefox.net wrote:
What's the easiest way to migrate from Pi4 to Pi5?
In this case I've a Pi4 running from a USB mechanical
hard disk. What I'd like to do is upgrade the existing
system OS to boot either Pi4 or Pi5, but I'm wary of
unintended consequences. The disk is fairly new and so
far has been reliable, so there's no strong incentive
to replace it.
Thanks for reading, and any suggestions.
The recommended way is a clean install of Bullseye on the Pi 5, but then
you get Wayland, Network manager and no rsyslog, and you'll have to sort
that lot out.
If the Pi 4 is using a 64 bit version of Buster, you can upgrade in
place despite the warnings.
If it is only running 32 bit Buster, then it's a bit more involved.
BTW; a USB SSD, as it will be vastly faster than a mechanical disc for running software. Keep the spinning rust for data.
---druck
On 05/06/2024 17:07, bp@www.zefox.net wrote:
What's the easiest way to migrate from Pi4 to Pi5?
In this case I've a Pi4 running from a USB mechanical
hard disk.
Why not use an SD card as the system disk, booting OS + apps and reserve
the hdd for data?
The trick is to separate app installation, executables etc, from data. I
get that from using Docker containers. It's worth looking at Docker
because life is just so much easier, in the long run. Not only does
Docker separate exes and data it also tends to script setup/config
making changes easier.
Yes sorry its bullseye to BOOKWORM
druck wrote:
Pi5 needs bookwork, which is the one that adds Wayland. The previous was >>> bullseye, not busterYes sorry its bullseye to BOOKWORM
Bookworm can provide also X11. It is the desktop that requires Wayland not Pi5 per se.
Pancho <Pancho.Jones@proton.me> wrote:
Why not use an SD card as the system disk, booting OS + apps and reserveI used to do that, before it was possible to boot from USB. There's
the hdd for data?
nothing wrong with it, excecpt that it requires a custom /etc/fstab.
Since the appearance of direct USB booting on the Pi3 eliminating
the microSD gets rid of one thing that can go wrong.
druck <news@druck.org.uk> wrote:
Yes sorry its bullseye to BOOKWORM
In light of private comments on bookworm's new "features" it
appears that I should set up a bookworm install and play with it
some. The existing Pi4 works very well under Bullseye, but it'll
get superceded at some point and I'll have to face Bookworm
eventually. In principle I like the idea of upgrading from X11,
though the actual experience may not be fun.....
One thing I hadn't considered until now is migrating away from
RasPiOS to something else. Are there any alternatives that offer
comparable support that will run on the Pi5? The biggest issue
for me is probably browser support, most other things I do are
in terminal windows running shells on FreeBSD hosts (also RPi,
but headless). I'm a less-bad admin with FreeBSD, but it does
not yet make use of the GPU on any Pi that I know of. AFAIK
FreeBSD can't yet boot on a Pi5.
One thing I hadn't considered until now is migrating away from
RasPiOS to something else. Are there any alternatives that offer
comparable support that will run on the Pi5? The biggest issue
for me is probably browser support,
One thing I hadn't considered until now is migrating away from
RasPiOS to something else. Are there any alternatives that offer
comparable support that will run on the Pi5? The biggest issue
for me is probably browser support,
One thing I hadn't considered until now is migrating away from
RasPiOS to something else. Are there any alternatives that offer
comparable support that will run on the Pi5?
In article <v3t15g$1kl11$1@dont-email.me>, <bp@www.zefox.net> wrote:
One thing I hadn't considered until now is migrating away from
RasPiOS to something else. Are there any alternatives that offer
comparable support that will run on the Pi5?
It depends on what you want to do.
serves as a headless OctoPrint host for my 3D printer. I've not tried running any of the desktop bits because I don't need them in that application. I've run Gentoo on various RPis, but updates can be painfully slow if you don't cross-compile them on more powerful hardware. I might've had Armbian running at one point (or maybe I'm confusing the RPi with other SBCs on which I've run Armbian).
None are going to be as easy to get up and running, but if you don't mind getting your hands dirty, they all have their uses and you'll learn
something from the experience. :)
Scott Alfter <scott@alfter.diespammersdie.us> wrote:
In article <v3t15g$1kl11$1@dont-email.me>, <bp@www.zefox.net> wrote:
One thing I hadn't considered until now is migrating away from
RasPiOS to something else. Are there any alternatives that offer >>>comparable support that will run on the Pi5?
It depends on what you want to do.
Probably browser performance is the main bottleneck. Far as I know
the RasPiOS version of chromium is the only browser that exploits
the VideoCore portion of the Pi.
Is this still true?
It's been a genuine dissapointment that Broadcom failed to open
VideoCore in a useful way. It's most of the Pi's horsepower. Or,
am I being unfair?
Via Mesa drivers, hardware 3D graphics rendering should be supported
in Firefox just like on PC, this has been the case for years. Check
the details on the about:support page to see whether Firefox on your
RPi has detected that it's available.
Of course it's really a matter of what you mean by "exploits". Even
pure framebuffer mode uses "the VideoCore portion of the Pi", so
what specific exploitation are you looking for?
I believe Chromium has HW video decoding on the Pi (not sure about
encoding), so that's probably what you mean. A quick search for
"Raspberry pi firefox hardware video decoding" brings up many
results announcing that support was added in Firefox 116. Note that
this means it's not available in the current Firefox ESR releases,
if you're using them.
It's been a genuine dissapointment that Broadcom failed to open
VideoCore in a useful way. It's most of the Pi's horsepower. Or,
am I being unfair?
If you're talking about video en/decoding, then yes that's a bit
unfair because Broadcom have made the APIs for common functionality
like that available. Also the Raspberry Pi developers have access to
all the secret documentation and development kits from Broadcom, and
it's the code that they've written for their fork of the Linux
kernel which has become some of the unofficial open-source reference
material for talking to the RPi's GPU. As the ones selling the
product, traditionally it's their job to submit code to projects
like Firefox to help get it supported if they so desire, or fork
them like they've done with the Linux kernel. Actually Firefox is
apparantly using a Linux kernel interface for this video decoding
support, so the RPi developers have up an API as conveniently as
possible and left the Firefox developers to take the last step of
using it at their end (quite a few years after Chromium, VLC,
FFmpeg, etc. did). So you could blame Mozilla too for being so
slow. Take your pick.
What Broadcom would enable by fully open-sourcing their GPU code
and documentation is that the firmware that these APIs talk to
could be expanded as well. Then extra GPU-accellerated functions
could be written such as for newer video codecs, or other things
entirely. By publishing the documentation for the QPU units in the
VideoCore IV GPUs Broadcom did open some doors towards that, but
it's not really enough information for a full open-source GPU
firmware to be independently developed (there's a project for that
with VideoCore IV, but it stalled years ago).
Computer Nerd Kev <not@telling.you.invalid> wrote:
Of course it's really a matter of what you mean by "exploits". Even
pure framebuffer mode uses "the VideoCore portion of the Pi", so
what specific exploitation are you looking for?
AIUI a GPU is a coprocessor with its own registers and cache that
can do single-instruction-multiple-data operations in parallel
with the CPU such as vector math. That's what I _think_ I'm looking
for. Compiler enhancements seem necessary, is that the bottleneck?
What Broadcom would enable by fully open-sourcing their GPU code
and documentation is that the firmware that these APIs talk to
could be expanded as well. Then extra GPU-accellerated functions
could be written such as for newer video codecs, or other things
entirely. By publishing the documentation for the QPU units in the VideoCore IV GPUs Broadcom did open some doors towards that, but
it's not really enough information for a full open-source GPU
firmware to be independently developed (there's a project for that
with VideoCore IV, but it stalled years ago).
Do other GPU companies (Nvidia comes to mind) handle things any better?
Computer Nerd Kev <not@telling.you.invalid> wrote:
Via Mesa drivers, hardware 3D graphics rendering should be supported
in Firefox just like on PC, this has been the case for years. Check
the details on the about:support page to see whether Firefox on your
RPi has detected that it's available.
Firefox is Extended Support Release 115.11.0esr(64-bit), installed using
apt. There's a checkbox to "use hardware acceleration when available"
but no hint whether it _is_ available or in use.
My browser of choice is chromium Version 124.0.6367.73 (Official Build)
Built on Debian , running on Debian 11 (64-bit). It seems a bit faster.
It also offers a checkbox "Use graphics acceleration when available"
without giving a hint of what it's actually using. I do remember that highligting the button caused trouble around a year ago.
Both are up-to-date according to apt.
Of course it's really a matter of what you mean by "exploits". Even
pure framebuffer mode uses "the VideoCore portion of the Pi", so
what specific exploitation are you looking for?
AIUI a GPU is a coprocessor with its own registers and cache that
can do single-instruction-multiple-data operations in parallel
with the CPU such as vector math. That's what I _think_ I'm looking
for. Compiler enhancements seem necessary, is that the bottleneck?
What Broadcom would enable by fully open-sourcing their GPU code
and documentation is that the firmware that these APIs talk to
could be expanded as well. Then extra GPU-accellerated functions
could be written such as for newer video codecs, or other things
entirely. By publishing the documentation for the QPU units in the
VideoCore IV GPUs Broadcom did open some doors towards that, but
it's not really enough information for a full open-source GPU
firmware to be independently developed (there's a project for that
with VideoCore IV, but it stalled years ago).
Do other GPU companies (Nvidia comes to mind) handle things any better?
druck <news@druck.org.uk> wrote:
Yes sorry its bullseye to BOOKWORM
In light of private comments on bookworm's new "features" it
appears that I should set up a bookworm install and play with it
some. The existing Pi4 works very well under Bullseye, but it'll
get superceded at some point and I'll have to face Bookworm
eventually. In principle I like the idea of upgrading from X11,
though the actual experience may not be fun.....
bp@www.zefox.net wrote:
Computer Nerd Kev <not@telling.you.invalid> wrote:
Via Mesa drivers, hardware 3D graphics rendering should be supported
in Firefox just like on PC, this has been the case for years. Check
the details on the about:support page to see whether Firefox on your
RPi has detected that it's available.
Firefox is Extended Support Release 115.11.0esr(64-bit), installed using
apt. There's a checkbox to "use hardware acceleration when available"
but no hint whether it _is_ available or in use.
The hints are all on the about:support page that I pointed you to.
To be specific, type "about:support#graphics" in the URL bar and press
Enter. There you'll find the specifics of what hardware accelleration
is used, or maybe a clue why it's not. You might need to look up the
terms used to see how they relate to the specific GPU accelleration
you want, but if my guess about your intentions is correct then look
at "HARDWARE_VIDEO_DECODING".
My browser of choice is chromium Version 124.0.6367.73 (Official Build)
Built on Debian , running on Debian 11 (64-bit). It seems a bit faster.
It also offers a checkbox "Use graphics acceleration when available"
without giving a hint of what it's actually using. I do remember that
highligting the button caused trouble around a year ago.
Both are up-to-date according to apt.
Debian package the ESR versions, but you could manually install the
Mozilla ARM64 Firefox binaries, though I think currently they're
only nightly builds, so the other extreme of stability. Firefox ESR
128 will be released on the 9th of July (Debian packages may take
some time longer to arrive).
Of course it's really a matter of what you mean by "exploits". Even
pure framebuffer mode uses "the VideoCore portion of the Pi", so
what specific exploitation are you looking for?
AIUI a GPU is a coprocessor with its own registers and cache that
can do single-instruction-multiple-data operations in parallel
with the CPU such as vector math. That's what I _think_ I'm looking
for. Compiler enhancements seem necessary, is that the bottleneck?
No the code running on the GPU is all written by Broadcom and Linux
software just talks to that, so nothing needs to be compiled for
the GPU in order to use functionality that's in the stock GPU
firmware. The bottleneck at this point seems to be mainly
application developers adding support for the APIs, but this isn't
an issue with compilers, just the usual limits of time, money, and
willpower.
If you want to do more with the GPU than using the routines
Broadcom's firmware includes, such as support en/decoding other
video codecs, or using it as a co-processor for non-graphics-related
tasks, then free compiler options become limited. That gets
complicated, but it's not much to do with PC-like GPU acceleration
in web browsers, that is already facilitated by Broadcom's
pre-compiled GPU firmware binary which runs on the GPU from
start-up (in fact it's what starts the CPU and Linux up).
What Broadcom would enable by fully open-sourcing their GPU code
and documentation is that the firmware that these APIs talk to
could be expanded as well. Then extra GPU-accellerated functions
could be written such as for newer video codecs, or other things
entirely. By publishing the documentation for the QPU units in the
VideoCore IV GPUs Broadcom did open some doors towards that, but
it's not really enough information for a full open-source GPU
firmware to be independently developed (there's a project for that
with VideoCore IV, but it stalled years ago).
Do other GPU companies (Nvidia comes to mind) handle things any better?
No, it's unlikely to be in their interest to release documents to
help others write open-source firmware for GPUs, because then
people could add features and performance improvements to cheaper
GPU chips that might reduce the market for their more expensive
models.
Still the degree of openness varies, overall Broadcom isn't
great, but better than Nvidia and no worse than others.
Much the same applies to other parts on the RPi boards like the WiFi/Bluetooth chips which also run closed-source firmware
binaries. There are other SBCs that try to use more "open
hardware", but the RPis prioritise low-cost ahead of that.
For what it's worth, I moved from Buster to Bookwrm on a
Pi4 recently. I really only use it for streaming movies. The
streaming services would no longer accept Firefox on Buster.
It maxed out at v. 92 if I remember correctly.
I was pleasantly surprised. I couldn't tell you what's different.
It just runs quicker and feels more solid on the same hardware.
It's a pleasure to see an update require *less* resources. All I
care about is getting Netflix, Kanopy, PBS, etc in Firefox. Now
that's working better than ever.
Computer Nerd Kev <not@telling.you.invalid> wrote:
No the code running on the GPU is all written by Broadcom and Linux
software just talks to that, so nothing needs to be compiled for
the GPU in order to use functionality that's in the stock GPU
firmware. The bottleneck at this point seems to be mainly
application developers adding support for the APIs, but this isn't
an issue with compilers, just the usual limits of time, money, and
willpower.
Ok, that clarifies things considerably. Is the API public, at least?
Then folks could experiment.
If you want to do more with the GPU than using the routines
Broadcom's firmware includes, such as support en/decoding other
video codecs, or using it as a co-processor for non-graphics-related
tasks, then free compiler options become limited. That gets
complicated, but it's not much to do with PC-like GPU acceleration
in web browsers, that is already facilitated by Broadcom's
pre-compiled GPU firmware binary which runs on the GPU from
start-up (in fact it's what starts the CPU and Linux up).
Is this to say that if somebody wanted to write a cryptocurrency
miner for the Raspberry Pi VideoCore they'd need Broadcom's help?
bp@www.zefox.net wrote:
Computer Nerd Kev <not@telling.you.invalid> wrote:
No the code running on the GPU is all written by Broadcom and Linux
software just talks to that, so nothing needs to be compiled for
the GPU in order to use functionality that's in the stock GPU
firmware. The bottleneck at this point seems to be mainly
application developers adding support for the APIs, but this isn't
an issue with compilers, just the usual limits of time, money, and
willpower.
Ok, that clarifies things considerably. Is the API public, at least?
Then folks could experiment.
Broadcom's API is DispmanX, which some programs have used directly,
but libbrcmEGL is their library that presents an OpenGL interface
and is thus easier to adapt software to. Separately the Linux
kernel now has its own drivers, which are used via Mesa. I'm not
sure how the performance compares, but the Mesa drivers are the
popular ones these days.
The trick is to separate app installation, executables etc, from data.
Since the appearance of direct USB booting on the Pi3 eliminating the
microSD gets rid of one thing that can go wrong.
It's interesting to find out where all this code comes from.
Broadcom have been more involved than I thought.
Indeed. It's interesting to note that about ten years have...
That's about how long it took from the advent of the i386 to
the general availability of *nix clones.
On Sun, 16 Jun 2024 23:42:41 -0000 (UTC)
<bp@www.zefox.net> wrote:
Indeed. It's interesting to note that about ten years have...
That's about how long it took from the advent of the i386 to
the general availability of *nix clones.
More like five years, the 80386 came out in 1987. There were BSD
ports available by 1993 and the first Linux release was in 1991. However that's just open source - There were commercial XENIX and Interactive ports earlier - even for the 80286.
Very hard to put a decent Unix on a 286 - Venix was the only one, I
recally. No memory management.
the 386 made porting unix pretty simple. SCO unix was extremely stable.
Wasn;'t that a Xenix evolution?
On Sun, 16 Jun 2024 23:42:41 -0000 (UTC)
<bp@www.zefox.net> wrote:
Indeed. It's interesting to note that about ten years have...
That's about how long it took from the advent of the i386 to
the general availability of *nix clones.
More like five years, the 80386 came out in 1987. There were BSD ports available by 1993 and the first Linux release was in 1991. However that's just open source - There were commercial XENIX and Interactive ports earlier - even for the 80286.
Ahem A Rivet's Shot <steveo@eircom.net> wrote:
On Sun, 16 Jun 2024 23:42:41 -0000 (UTC)
More like five years, the 80386 came out in 1987. There were
BSD ports available by 1993 and the first Linux release was in 1991. However that's just open source - There were commercial XENIX and Interactive ports earlier - even for the 80286.
We're comparing different endpoints. I started with 386BSD and it
could be made to install and run by about 1992, but that alone was
an accomplishment for a non-expert like me. It took a few more
years to become _usable_ by non-experts, in the form of FreeBSD.
Maybe I'm off a little on the dates (I learned of 386BSD about a
year after the Byte Magazine series by Jolitz) but then it was
still very fiddly. By about 1997-8 I was using FreeBSD for email.
Others were doubtless quicker on the uptake, but they were a select
On Mon, 17 Jun 2024 18:03:37 -0000 (UTC)
<bp@www.zefox.net> wrote:
Ahem A Rivet's Shot <steveo@eircom.net> wrote:
On Sun, 16 Jun 2024 23:42:41 -0000 (UTC)
More like five years, the 80386 came out in 1987. There were
BSD ports available by 1993 and the first Linux release was in 1991.
However that's just open source - There were commercial XENIX and
Interactive ports earlier - even for the 80286.
We're comparing different endpoints. I started with 386BSD and it
could be made to install and run by about 1992, but that alone was
an accomplishment for a non-expert like me. It took a few more
Indeed it was - did you have the patch kit ?
years to become _usable_ by non-experts, in the form of FreeBSD.
Nope FreeBSD 1.0 came out in November 1993 - I was using 1.1.5.1 to run a Dublin based ISP in 1994. We gave Jordan Hubbard a free account when
we discovered he was visiting Ireland and he gave us a stack of 1.1 discs.
He got the better deal :)
Maybe I'm off a little on the dates (I learned of 386BSD about a
year after the Byte Magazine series by Jolitz) but then it was
still very fiddly. By about 1997-8 I was using FreeBSD for email.
That would be late 2.2 or early 3.0 days - 3.0 was the release that included APM support for laptops, one of the few occasions I ran -current.
IIRC 1.1.5.1 worked pretty well, as the last encumbered version. Am I confused? The early un-encumbered versions were somewhat rough.
[encumbered meaning "contains AT&T code"]
On 06/06/2024 19:24, bp@www.zefox.net wrote:
Pancho <Pancho.Jones@proton.me> wrote:
Why not use an SD card as the system disk, booting OS + apps and reserve >>> the hdd for data?I used to do that, before it was possible to boot from USB. There's
nothing wrong with it, excecpt that it requires a custom /etc/fstab.
Since the appearance of direct USB booting on the Pi3 eliminating
the microSD gets rid of one thing that can go wrong.
You shouldn't need to customise /etc/fstab with USB data discs as they
will be automatically mounted in /media unless you want them mounted elsewhere.
At this point both machines are on the same 192.168.1.y network, butHang on a minute.
they don't seem able to communicate at all, simply reporting
"no route to host" from either end. Ping fails, losing all packets.
It looks like sshd is running, based on ps output.
Both machines are connecting via DHCP, so the WAP is the default route
for both. Do I need to do something special to use sftp between them?
At this point both machines are on the same 192.168.1.y network, but
they don't seem able to communicate at all, simply reporting
"no route to host" from either end. Ping fails, losing all packets.
Hang on a minute.
Both machines are connecting via DHCP, so the WAP is the default route
for both. Do I need to do something special to use sftp between them?
Is the WAP capable of routing?
I assumed you had a proper router somewhere doing routing and DHCP and
the WAP was merely bridging to it
From where is the ssh working?b sftp IS ssh.
The Natural Philosopher <tnp@invalid.invalid> wrote:
Hang on a minute.
Both machines are connecting via DHCP, so the WAP is the default route
for both. Do I need to do something special to use sftp between them?
Is the WAP capable of routing?
I assumed you had a proper router somewhere doing routing and DHCP and
the WAP was merely bridging to it
I didn't think routing would be needed, since both hosts are on the
same network.
The Pi5 is at 192.168.1.10,
the Pi4 is at 192.168.1.11
a printer at 192.168.1.250
and a Mac at 192.168.1.22
Both Pi4 and Pi5 can ping the printer sucessfully.
Neither Pi can ping the other, nor the Mac.
both can ping themselves using their assigned IP number.
The Mac can ping the printer but neither Pi.
From where is the ssh working?b sftp IS ssh.
It works to the WAN, no problem. I don't think I've tried using
ssh/sftp across the LAN until now, or at least not recently.
The Pi4 is running Bullseye, the Pi5 Bookworm.
Thanks for writing!
bob prohaska
At this point both machines are on the same 192.168.1.y network, but
they don't seem able to communicate at all, simply reporting
"no route to host" from either end. Ping fails, losing all packets.
It looks like sshd is running, based on ps output.
On 25/06/2024 18:20, bp@www.zefox.net wrote:
The Natural Philosopher <tnp@invalid.invalid> wrote:
Hang on a minute.
Both machines are connecting via DHCP, so the WAP is the default route >>>> for both. Do I need to do something special to use sftp between them?
Is the WAP capable of routing?
I assumed you had a proper router somewhere doing routing and DHCP and
the WAP was merely bridging to it
I didn't think routing would be needed, since both hosts are on the
same network.
The Pi5 is at 192.168.1.10,
the Pi4 is at 192.168.1.11
a printer at 192.168.1.250
and a Mac at 192.168.1.22
Both Pi4 and Pi5 can ping the printer sucessfully.
Neither Pi can ping the other, nor the Mac.
both can ping themselves using their assigned IP number.
The Mac can ping the printer but neither Pi.
From where is the ssh working?b sftp IS ssh.
It works to the WAN, no problem. I don't think I've tried using
ssh/sftp across the LAN until now, or at least not recently.
The Pi4 is running Bullseye, the Pi5 Bookworm.
Thanks for writing!
bob prohaska
What netmask are using on these devices? 192.168 can be either B or C
On Mon, 24 Jun 2024 22:28:01 -0000 (UTC)
<bp@www.zefox.net> wrote:
At this point both machines are on the same 192.168.1.y network, but
they don't seem able to communicate at all, simply reporting
"no route to host" from either end. Ping fails, losing all packets.
It looks like sshd is running, based on ps output.
Is the WAP configured to block traffic between clients ? That seems to be the default with many consumer WAPs.
Ahem A Rivet's Shot <steveo@eircom.net> wrote:
On Mon, 24 Jun 2024 22:28:01 -0000 (UTC)
<bp@www.zefox.net> wrote:
At this point both machines are on the same 192.168.1.y network, but
they don't seem able to communicate at all, simply reporting
"no route to host" from either end. Ping fails, losing all packets.
It looks like sshd is running, based on ps output.
Is the WAP configured to block traffic between clients ? That
seems to be the default with many consumer WAPs.
I think the answer is "no". There is an "advanced" tab in the router
config mentioning IP filters, but explains "Use IP Filters to deny
On Tue, 25 Jun 2024 19:53:11 -0000 (UTC)
<bp@www.zefox.net> wrote:
Ahem A Rivet's Shot <steveo@eircom.net> wrote:
On Mon, 24 Jun 2024 22:28:01 -0000 (UTC)
<bp@www.zefox.net> wrote:
At this point both machines are on the same 192.168.1.y network, but
they don't seem able to communicate at all, simply reporting
"no route to host" from either end. Ping fails, losing all packets.
It looks like sshd is running, based on ps output.
Is the WAP configured to block traffic between clients ? That
seems to be the default with many consumer WAPs.
I think the answer is "no". There is an "advanced" tab in the router
config mentioning IP filters, but explains "Use IP Filters to deny
It's usually called something to do with isolation "wireless" or "client" most often. I'd be surprised if there wasn't the option.
Could this be some sort of security feature? In a classroom
environment direct communication between student workstations
might be worth suppressing, especially at exam time 8-)
<bp@www.zefox.net> writes:And if it isnt the main dhcp server, disable it for DHCP as well
Could this be some sort of security feature? In a classroom
environment direct communication between student workstations
might be worth suppressing, especially at exam time 8-)
Yes, some WAPs have a feature like that so clients connected to it can't
see each other. It seems like a common thing to do in open and
semi-secure WLANs.
So, check the settings of your WAP.
At this point both machines are on the same 192.168.1.y network, but
they don't seem able to communicate at all, simply reporting
"no route to host" from either end. Ping fails, losing all packets.
It looks like sshd is running, based on ps output.
Although the Pi 3B has both 2.4 and 5, it was far away from the AP
druck wrote:
Although the Pi 3B has both 2.4 and 5, it was far away from the AP
Are you saying you added a USB 5GHz dongle? Because otherwise an rPi
3B is 2.4GHz only ...
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 371 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 37:35:45 |
| Calls: | 7,932 |
| Calls today: | 2 |
| Files: | 12,998 |
| Messages: | 5,805,631 |