• Raspberry Pi 4's IP Address 169...

    From Patrick Zacharczyp@3:770/3 to All on Fri Jan 7 11:18:56 2022
    My Raspberry Pi 4 that I got recently has a 169.XX. IP address and I am trying to get it connected to the internet and install something. This happened to my other Raspberry Pi. Could someone help me? I tried doing some things in my router and I even
    used a command to add a static IP. I used a USB 3.0 to ethernet adaptor w/ my last Pi, and it worked, but it couldn't update. Someone please help as I spent a lot of money on this.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From TimS@3:770/3 to patrick.zacharczyp@bccaschools.org on Sat Jan 8 14:02:48 2022
    On 07 Jan 2022 at 19:18:57 GMT, Patrick Zacharczyp <patrick.zacharczyp@bccaschools.org> wrote:

    My Raspberry Pi 4 that I got recently has a 169.XX. IP address and I am trying to get it connected to the internet and install something. This happened to my other Raspberry Pi. Could someone help me? I tried doing some things in my router and I even
    used a command to add a static IP. I used a USB 3.0 to ethernet adaptor w/ my last Pi, and it worked, but it couldn't update. Someone please help as I spent a lot of money on this.

    Your router should be supplying it with an IP address There ought to be a Network Control Panel or similar somewhere under Settings where you can tell the Pi to use DHCP. Then the router will supply it with an IP address.
    --
    Tim

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Marco Moock@3:770/3 to All on Sun Jan 9 09:42:52 2022
    Am Samstag, 08. Januar 2022, um 20:55:50 Uhr schrieb NY:

    "Marco Moock" <mo01@posteo.de> wrote in message news:20220108183111.318f397f@ryz...
    Am Samstag, 08. Januar 2022, um 14:52:07 Uhr schrieb NY:

    "Marco Moock" <mo01@posteo.de> wrote in message

    There is the possibility that Wireshark run on *another* computer
    may not see much of the DHCP conversation because the network
    switch in the router may filter out traffic that is not from/to
    the computer that is running Wireshark. However I think that the
    initial DHCP broadcast or multicast from the Pi should should up.

    No, the DHCPv4 discovery message from the Pi is being sent to the
    broadcast MAC address (FF:FF:FF:FF:FF:FF). Every switch has to sent
    out that frame on every port except the port it came from.

    Yes I imagine the first part of the DHCP conversation is at broadcast
    level. I couldn't remember how far through the process it stayed at
    broadcast level before becoming a point-to-point conversation. Though thinking about it, the client (the Pi) doesn't *know* what its IP
    address is until the end of the conversation when the DHCP server has
    said "yes, you really *can* use the address that I proposed earlier
    in the conversation".

    The DHCPCPv4 offer could already be an Ethernet unicast frame because
    the DHCPv4 server know the MAC address of the DHCPv4 client. The DHCPv4
    request can also be a unicast frame because the client knows the MAC
    address from the server.

    I wasn't sure what IP address "ip a" would report if a computer was statically configured to use an IP address that happened to clash
    with one being used by another computer (whether that second computer
    got its IP statically or by DHCP). In other words, if "ip a" is
    reporting a 169.a.b.c address, does that imply that the Pi is
    configured to use DHCP, or could it alternatively mean that it is
    configured statically but there is an IP clash.

    ip a just shows what addresses are assigned to an interface - not how
    they were assigned.
    There is the IPv4 link-local range 169.254.0.0/16. This is normally
    being used if DHCPv4 is enabled, but no DHCP server responds.
    You can set them manually, but you shouldn't according to RFC3927.
    IIRC, they are only assigned if DHCPv4 fails and not if an address
    conflict exists.

    I'm still puzzled by why he has had the problem on more than one Pi
    and why he's using an external USB-Ethernet adaptor rather than the
    built-in Ethernet port: I bet one or other of those is at the root of
    why he's having problems getting DHCP to work.

    The only possibility to find that out is sniffing all the traffic
    between Pi and the DHCP server. The MAC address/client identifier might
    be the issue.

    Suppose the 169 address relates to the built-in adaptor and not the
    external one. Suppose the external one isn't even listed because it's
    not working due to a lack of drivers.

    "ip a" should reveal all...

    True, because ip a shows interfaces that are usable. Some that don't
    have a working driver are not shown.


    The important section is the "eth0" section. Note that my router is configured (for obscure reasons) to hand out addresses 10.120.1.x
    which is another private address range like 192.168.x.y and
    172.a.b.c.

    172.0.0.0/8 isn't completely a private IPv4 network.
    172.16.0.0/12 is the private range of that network.

    See https://datatracker.ietf.org/doc/html/rfc1918 and https://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Marco Moock on Sun Jan 9 15:05:22 2022
    On 09/01/2022 08:42, Marco Moock wrote:
    The DHCPCPv4 offer could already be an Ethernet unicast frame because
    the DHCPv4 server know the MAC address of the DHCPv4 client. The DHCPv4 request can also be a unicast frame because the client knows the MAC
    address from the server.

    The first message MUST be a broadcast since neither end knows the (MAC/Ethernet) location of the other.

    I actually spend some time tracing an issue with DHCP, and the best
    place to out the tracer is on the machine requesting the address. It
    sees one side of the conversation at least...


    --
    "What do you think about Gay Marriage?"
    "I don't."
    "Don't what?"
    "Think about Gay Marriage."

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to All on Sun Jan 9 15:00:56 2022
    On 08/01/2022 20:55, NY wrote:
    "Marco Moock" <mo01@posteo.de> wrote in message news:20220108183111.318f397f@ryz...
    Am Samstag, 08. Januar 2022, um 14:52:07 Uhr schrieb NY:

    "Marco Moock" <mo01@posteo.de> wrote in message

    There is the possibility that Wireshark run on *another* computer may
    not see much of the DHCP conversation because the network switch in
    the router may filter out traffic that is not from/to the computer
    that is running Wireshark. However I think that the initial DHCP
    broadcast or multicast from the Pi should should up.

    No, the DHCPv4 discovery message from the Pi is being sent to the
    broadcast MAC address (FF:FF:FF:FF:FF:FF). Every switch has to sent out
    that frame on every port except the port it came from.

    Yes I imagine the first part of the DHCP conversation is at broadcast
    level. I couldn't remember how far through the process it stayed at
    broadcast level before becoming a point-to-point conversation. Though thinking about it, the client (the Pi) doesn't *know* what its IP
    address is until the end of the conversation when the DHCP server has
    said "yes, you really *can* use the address that I proposed earlier in
    the conversation".

    Pi does an all stations broadcast 'I am on this ETHERNET address if
    there is a DHCP server out there, please tell me who I am (sounds of supertramp)

    After that its all done by ethernet address and on a switch you wont see
    any of that unless you set up tcpdump on the Pi.

    Which is not a bad way to go actually.



    I wasn't sure what IP address "ip a" would report if a computer was statically configured to use an IP address that happened to clash with
    one being used by another computer (whether that second computer got its
    IP statically or by DHCP). In other words, if "ip a" is reporting a
    169.a.b.c address, does that imply that the Pi is configured to use
    DHCP, or could it alternatively mean that it is configured statically
    but there is an IP clash.

    Neither. it tells you nothing. Except that the interface is configured
    to an address.

    Ther is almost nothing in the IP protocol to prevent two interfaces
    being on the same IP address,


    I'm still puzzled by why he has had the problem on more than one Pi and
    why he's using an external USB-Ethernet adaptor rather than the built-in Ethernet port: I bet one or other of those is at the root of why he's
    having problems getting DHCP to work.

    Indeed. The auto DHCP will work for the primary ethernet adapter. No
    idea how you adjust it for a second port



    --
    "Women actually are capable of being far more than the feminists will
    let them."

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From druck@3:770/3 to Marco Moock on Mon Jan 10 08:21:44 2022
    On 08/01/2022 12:02, Marco Moock wrote:
    Am Freitag, 07. Januar 2022, um 11:18:57 Uhr schrieb Patrick Zacharczyp:

    My Raspberry Pi 4 that I got recently has a 169.XX. IP address and I
    am trying to get it connected to the internet and install something.
    This happened to my other Raspberry Pi. Could someone help me? I
    tried doing some things in my router and I even used a command to add
    a static IP. I used a USB 3.0 to ethernet adaptor w/ my last Pi, and
    it worked, but it couldn't update. Someone please help as I spent a
    lot of money on this.

    Please post the output of
    ip a

    From that you'll see the name of the Ethernet adaptor, the built in one
    is usually eth0

    Use a network Sniffer like Wireshark (maybe on another computer) and
    sniff for DHCPv4 packages. Check if the Pi sends out a DHCP Discovery.

    A bit easier than that would be to do a manual DHCP discovery and see
    what output you get, with:-

    dhclient -v eth0

    ---druck

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From NY@3:770/3 to All on Wed Jan 12 23:28:58 2022
    "Ahem A Rivet's Shot" <steveo@eircom.net> wrote in message news:20220112202158.5e397cc08e31a52f8b8fa626@eircom.net...
    Yup.
    I was pondering the first modem I saw around 1972. 50 baud and an
    acoustic coupler.

    I'm pretty sure the first one I saw in 1975 was 300 baud on an
    acoustic coupler - it could keep up with an ASR-33 reader/punch.

    Yes I remember the old 300 baud acoustic coupler: a polished wooden box,
    lined with green baize with mic/speaker "holes" which exactly matched the handset of a standard GPO/BT telephone. That was the comms between the
    teletype that we had at school and the mainframe computer that we accessed -
    in the late 70s. The teletype was painfully slow, but sometimes we could see
    it stall for a second if the comms couldn't keep up.


    By 1982 ir was 300 baud
    By 1992 we were happy at 9600...

    About that time 14,400 came in, then 28.8, 33.6 quite rapidly and
    then the asymmetric standards with a digital signal on one end and a modem
    on the other (V90, V92).

    Yes I remember a friend had a standard 28.8 kbps modem for accessing the internet by dialup. I bought my modem a bit later than him, and 33.6 became possible. I think my modem was US Robotics. I've got a feeling that a PROM upgrade became available that allowed it to work a little bit faster than
    that, as long as the other end could use the correct protocol.


    Then "broadband" started to be the word on everyone's lips. There was talk
    of some large towns having their exchanges upgraded to support ADSL, but
    those in villages needed to get more than a certain "trigger level" of firm orders (via ISPs) before BT would even consider upgrading them. In the meantime, a group of us on my housing estate investigated a long-range microwave link to a mast on a nearby hill: companies were setting up in business to supply fast internet this way for places that had not yet
    reached their BT trigger.

    Suddenly came the announcement we never thought we'd hear: BT were
    abandoning the concept of trigger levels and were committing to add ADSL to every exchange. I lived about 200 metres from my exchange so I knew that I'd
    be able to get up to 8 Mbps. Initially ISPs (because of BT) were charging various amounts depending on what speed you wanted - or could achieve due to line length. I initially opted for 2 Mbps down and 448 k bps up, because 8
    Mbps was a lot more expensive. But the price differential got smaller and smaller, so I upgraded to 8 Mbps. Still only 448 kbps upload, though :-(

    That situation lasted until "fibre". We got FTTC and managed about 15 Mbps
    down and about 5 bps up. Not a huge increase in download speed, but a tremendous increase in upload speed when FTPing files to a server.

    At our present house we get about 25-35 down and about 8-10 up. The sync
    speed fluctuates, taking roughly two weeks to go between one extreme and the other. I'm sure if we had brand new wiring from where the drop cable
    terminates at the old GPO lozenge box on the gable end, to the socket where
    the router is plugged in, we'd get a slightly better speed. But it would be
    a major job involving crawl boards on the roof to get at that socket and to
    run new cable (with no junctions along the way) to the living room - and
    it's difficult to know where the demarcation is between BT and owner
    cabling. Maybe it's at the first BT socket rather than the GPO box.

    It looks as if our village is being cabled up for FTTP, as part of BT's
    phasing out of copper connections. That will cause some interesting problems because the point where the BT cable comes into the house (and therefore
    where they'd *probably* bring the fibre) has no mains socket near and no way
    of running a mains cable without taking up a carpet (which means moving a
    lot of furniture) to dig a channel in the concrete floor to run a spur from
    the nearest socket on the ring main. And you *need* mains for the fibre-to-Ethernet converter (I've forgotten what BT call it).

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Axel Berger@3:770/3 to Ahem A Rivet's Shot on Thu Jan 13 13:47:22 2022
    Ahem A Rivet's Shot wrote:
    I'm pretty sure the first one I saw in 1975 was 300 baud on an
    acoustic coupler - it could keep up with an ASR-33 reader/punch.

    Fast enough before everything got silly. I tried it out. I can read text
    at up to 300 baud and I can scan text, to find where to stop, at 1200
    baud. Anything above that becomes a useless blur.


    --
    /\ No | Dipl.-Ing. F. Axel Berger Tel: +49/ 221/ 7771 8067
    \ / HTML | Roald-Amundsen-Strae 2a Fax: +49/ 221/ 7771 8069
    X in | D-50829 Kln-Ossendorf http://berger-odenthal.de
    / \ Mail | -- No unannounced, large, binary attachments, please! --
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Ahem A Rivet's Shot@3:770/3 to Axel Berger on Thu Jan 13 14:06:56 2022
    On Thu, 13 Jan 2022 13:47:23 +0100
    Axel Berger <Spam@Berger-Odenthal.De> wrote:

    Ahem A Rivet's Shot wrote:
    I'm pretty sure the first one I saw in 1975 was 300 baud on an
    acoustic coupler - it could keep up with an ASR-33 reader/punch.

    Fast enough before everything got silly. I tried it out. I can read text

    What silly like things that aren't text ?

    Then again I used to think that sending a screenshot image instead
    of typing a bit of text was the extreme of lazy bandwidth waste - until I
    got sent a high definition video panning around a screen at close range from which I was expected to glean two small pieces of essential text - needless
    to say one was obscured by glare.

    --
    Steve O'Hara-Smith
    Odds and Ends at http://www.sohara.org/

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Dennis Lee Bieber@3:770/3 to All on Thu Jan 13 13:39:08 2022
    On Thu, 13 Jan 2022 09:36:56 -0000, "NY" <me@privacy.invalid> declaimed the following:


    Now that I didn't know. So maybe that explains why my old Win 7 laptop would >not go much above that speed even when I was close to the router on an >uninterfered-with channel with no other traffic on wifi. I thought the >built-in wifi adaptor was failing, but maybe it was never designed to go
    much faster.

    Peruse https://en.wikipedia.org/wiki/IEEE_802.11#Protocol and modified by https://en.wikipedia.org/wiki/IEEE_802.11#Common_misunderstandings_about_achievable_throughput



    --
    Wulfraed Dennis Lee Bieber AF6VN
    wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Dennis Lee Bieber on Thu Jan 13 19:33:04 2022
    On 13/01/2022 18:39, Dennis Lee Bieber wrote:
    On Thu, 13 Jan 2022 09:36:56 -0000, "NY" <me@privacy.invalid> declaimed the following:


    Now that I didn't know. So maybe that explains why my old Win 7 laptop would >> not go much above that speed even when I was close to the router on an
    uninterfered-with channel with no other traffic on wifi. I thought the
    built-in wifi adaptor was failing, but maybe it was never designed to go
    much faster.

    Peruse https://en.wikipedia.org/wiki/IEEE_802.11#Protocol and modified by https://en.wikipedia.org/wiki/IEEE_802.11#Common_misunderstandings_about_achievable_throughput


    ]
    Not bad, but with caeveats

    They don't understand spread spectrum ...there is no such thing as
    'channel width - what there is is adjacent channel crosstalk that
    diminishes as the channels get 'less adjacent',

    Spread spectrum is destined for high availability and freedom from
    blocking by single frequencies in crowded spectrum space and when I was
    working next door to its secret development, it was for battlefield radios.

    It ended up in mobile phones, and then wifi.

    The ideas is that you 'smear' the information over a large section of
    spectrum, using a special secret code such that you cant kill the whole
    signal with a strong carrier.

    Some implementations use frequency hopping as well - so the center
    channel frequency moves around again to throw off potential
    interference. Wifi doesn't though.

    Pretty sure that some wifi implentations use two widely spaced channels
    to double the throughput


    so each transmitter and receiver pair exchange data that is all over
    half a dozen channels at varying strengths at the same time. So you only
    get the signals belonging to you - everyone else's sound like noise.
    Leastways that is how it worked for the military and I think GSM. Wifi
    may in fact use one code per wifi point. And do the separation into wifi devices using coding at the digital level


    Needless to say data rate is as always governed by Shannon - so the more
    other stuff is going on the slower the links will be.,





    --
    "Strange as it seems, no amount of learning can cure stupidity, and
    higher education positively fortifies it."

    - Stephen Vizinczey
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From meff@3:770/3 to The Natural Philosopher on Thu Jan 13 19:48:42 2022
    On 2022-01-13, The Natural Philosopher <tnp@invalid.invalid> wrote:
    Needless to say data rate is as always governed by Shannon - so the more other stuff is going on the slower the links will be.,

    We are _far_ from information theoretic upper bounds on our links,
    just FYI. Coding and frequency-division schemes for mobile networks
    can also be a lot more complicated (like CDMA).
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to meff on Thu Jan 13 19:55:42 2022
    On 13/01/2022 19:48, meff wrote:
    On 2022-01-13, The Natural Philosopher <tnp@invalid.invalid> wrote:
    Needless to say data rate is as always governed by Shannon - so the more
    other stuff is going on the slower the links will be.,

    We are _far_ from information theoretic upper bounds on our links,
    just FYI. Coding and frequency-division schemes for mobile networks
    can also be a lot more complicated (like CDMA).

    I dont think so at ALL.
    examination of stuff like ADSL shows we are within a factor of two of
    shannon limits


    For a 22MHz wifi channel at say 30dB s/n, you are looking at around 660
    Mbps shannon limit.

    Its the same order of magnitude as the achievable maxima.





    --
    It is the folly of too many to mistake the echo of a London coffee-house
    for the voice of the kingdom.

    Jonathan Swift
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From NY@3:770/3 to The Natural Philosopher on Thu Jan 13 20:26:04 2022
    "The Natural Philosopher" <tnp@invalid.invalid> wrote in message news:srpupi$ols$1@dont-email.me...
    They don't understand spread spectrum ...there is no such thing as
    'channel width - what there is is adjacent channel crosstalk that
    diminishes as the channels get 'less adjacent',

    I thought that wifi did have a defined bandwidth depending on the comms
    speed (ie which 802.11 standard it supports). I've always understood that channels 1, 6 and 11 are guaranteed not to overlap (at least for the earlier standards) and therefore you get no further benefit from using channels
    spaced more widely than 1, 6, 11, but that you get progressively more degradation as you move the channels closer than 1, 6, 11.

    Spread spectrum is destined for high availability and freedom from
    blocking by single frequencies in crowded spectrum space and when I was working next door to its secret development, it was for battlefield
    radios.

    It ended up in mobile phones, and then wifi.

    The ideas is that you 'smear' the information over a large section of spectrum, using a special secret code such that you cant kill the whole signal with a strong carrier.

    Sounds good. Which wireless standards support it, as an alternative to
    channels that are spaced more closely than the bandwidth of any given comms link (as you have with 2.4 GHz). Whenever I've run wifi spectrum analysis software, it's always shown me specific channel number for each wifi network that is in range, and the number of channels either side that each network
    is using. Spread spectrum is completely different and as long as there are holes at irregular places in the spectrum, a spread spectrum will use it.
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to All on Thu Jan 13 20:42:44 2022
    On 13/01/2022 20:26, NY wrote:
    "The Natural Philosopher" <tnp@invalid.invalid> wrote in message news:srpupi$ols$1@dont-email.me...
    They don't understand spread spectrum ...there is no such thing as
    'channel width - what there is is adjacent channel crosstalk that
    diminishes as the channels get 'less adjacent',

    I thought that wifi did have a defined bandwidth depending on the comms
    speed (ie which 802.11 standard it supports). I've always understood
    that channels 1, 6 and 11 are guaranteed not to overlap (at least for
    the earlier standards) and therefore you get no further benefit from
    using channels spaced more widely than 1, 6, 11, but that you get progressively more degradation as you move the channels closer than 1,
    6, 11.

    Well 'guaranteed not to overlap' is ArtStudent talk for 'show < -60dB
    adjacent channel crosstalk' and so on

    Radio is intensely analogue. Spectra don't have sharp edges!


    Spread spectrum is destined for high availability and freedom from
    blocking by single frequencies in crowded spectrum space and when I
    was working next door to its secret development, it was for
    battlefield radios.

    It ended up in mobile phones, and then wifi.

    The ideas is that you 'smear' the information over a large section of
    spectrum, using a special secret code such that you cant kill the
    whole signal with a strong carrier.

    Sounds good. Which wireless standards support it, as an alternative to channels that are spaced more closely than the bandwidth of any given
    comms link (as you have with 2.4 GHz). Whenever I've run wifi spectrum analysis software, it's always shown me specific channel number for each
    wifi network that is in range, and the number of channels either side
    that each network is using. Spread spectrum is completely different and
    as long as there are holes at irregular places in the spectrum, a spread spectrum will use it.


    No, wifi is spread spectrum. If you like its as if the frequency at any
    given time is somewhere within 22Mhz of a given centre frequency, and is constantly moving around, or you could say its heavily modulated by a
    high frequency noise (a pseudorandom code) that its energy is spread
    across several channels . Thats why you need to de convolute it with the
    same pseudo random code in order to make sense of it.

    The whole idea is to get away from any natural signals that might
    'look' the same.

    Oh heck, why have a dog and bark?

    Here's a pretty decent write up

    https://dsp.stackexchange.com/questions/2844/what-exactly-happens-with-spread-spectrum-modulation



    --
    Ideas are more powerful than guns. We would not let our enemies have
    guns, why should we let them have ideas?

    Josef Stalin
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Ahem A Rivet's Shot@3:770/3 to me@privacy.invalid on Thu Jan 13 20:46:20 2022
    On Thu, 13 Jan 2022 20:26:05 -0000
    "NY" <me@privacy.invalid> wrote:

    Sounds good. Which wireless standards support it, as an alternative to

    All the "wifi" and bluetooth standards are spread spectrum based.

    channels that are spaced more closely than the bandwidth of any given
    comms link (as you have with 2.4 GHz). Whenever I've run wifi spectrum analysis software, it's always shown me specific channel number for each

    More detail than you probably want to know:

    <http://webpages.eng.wayne.edu/~ad5781/ECECourses/ECE5620/Notes/Wi-Fi-Lecture.pdf>

    wifi network that is in range, and the number of channels either side
    that each network is using. Spread spectrum is completely different and
    as long as there are holes at irregular places in the spectrum, a spread spectrum will use it.

    TL;DR Wifi and bluetooth are spread spectrum using many very narrow channels spread around a fairly narrow space, this is why the effect of crowding APs too closely is a slowdown rather than a stop.

    --
    Steve O'Hara-Smith
    Odds and Ends at http://www.sohara.org/
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From NY@3:770/3 to The Natural Philosopher on Thu Jan 13 21:28:50 2022
    "The Natural Philosopher" <tnp@invalid.invalid> wrote in message news:srq2s5$mfh$1@dont-email.me...
    Well 'guaranteed not to overlap' is ArtStudent talk for 'show < -60dB adjacent channel crosstalk' and so on

    Radio is intensely analogue. Spectra don't have sharp edges!


    No, but there comes a point (eg your -60 dB) beyond which there is no *discernable* difference in terms of speed, absence of glitches or however
    you measure it. In common parlance that is "no overlapping".

    That's why I described channels 1, 6 and 11 as non-overlapping, meaning data rate of a comms link using one channel is not degraded if another link
    starts up on a no-overlapping channel (or spaced more widely than that) and that conversely if the second channel is closer than that limit, you get progressively worse data rate or glitches as the two channels move closer together in frequency.

    In other words, taking the pragmatic engineering attitude rather than the theoretical physical / mathematical approach of very wide bandwidth even if
    the edges are so weak that they aren't distinguishable from noise.


    No, wifi is spread spectrum. If you like its as if the frequency at any
    given time is somewhere within 22Mhz of a given centre frequency, and is constantly moving around, or you could say its heavily modulated by a high frequency noise (a pseudorandom code) that its energy is spread across several channels . Thats why you need to de convolute it with the same
    pseudo random code in order to make sense of it.

    The whole idea is to get away from any natural signals that might 'look'
    the same.

    Oh heck, why have a dog and bark?

    Here's a pretty decent write up

    https://dsp.stackexchange.com/questions/2844/what-exactly-happens-with-spread-spectrum-modulation

    I'll read that. Thanks.

    I've heard of deliberately convoluting a signal in such a way that it looks like noise, and then applying an inverse convolution at the other end. I
    think one of the design criteria for DVB TV signals was that they had to
    look like noise so they didn't produce noticeable patterning on analogue TVs
    if there happened to be a bit of co-channel interference. Obviously that requirement no longer applies now that analogue TV is no longer broadcast or received. I have an old analogue-only TV which I;ve never got round throwing away because it could still be used as a monitor or with an external DVB decoder, and if I let that scan, I can see that the amount of "snow"
    increases as it tunes across each of the multiplexes broadcast by the TV transmitter. Weird to think that this snow is actually digital TV channels
    ;-)

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Dennis Lee Bieber@3:770/3 to All on Thu Jan 13 16:41:20 2022
    On Thu, 13 Jan 2022 20:26:05 -0000, "NY" <me@privacy.invalid> declaimed the following:

    "The Natural Philosopher" <tnp@invalid.invalid> wrote in message >news:srpupi$ols$1@dont-email.me...

    I thought that wifi did have a defined bandwidth depending on the comms
    speed (ie which 802.11 standard it supports). I've always understood that >channels 1, 6 and 11 are guaranteed not to overlap (at least for the earlier >standards) and therefore you get no further benefit from using channels >spaced more widely than 1, 6, 11, but that you get progressively more >degradation as you move the channels closer than 1, 6, 11.

    But when you've got something like 6 neighbors all using "optimal" channels 1/6/11 -- you might be better off on channel 3/4 where you might
    not be getting channel usage congestion/collisions...



    --
    Wulfraed Dennis Lee Bieber AF6VN
    wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Axel Berger@3:770/3 to Dennis Lee Bieber on Thu Jan 13 22:49:08 2022
    Dennis Lee Bieber wrote:
    But when you've got something like 6 neighbors all using "optimal" channels 1/6/11 -- you might be better off on channel 3/4 where you might
    not be getting channel usage congestion/collisions...

    I always use channel 13 and I'm always the only one on it. With everyone
    elso on "auto" even channel 11 is rarely used and if so it's usually
    very weak. It seems they all begin on 1 and only move up when needed.


    --
    /\ No | Dipl.-Ing. F. Axel Berger Tel: +49/ 221/ 7771 8067
    \ / HTML | Roald-Amundsen-Strae 2a Fax: +49/ 221/ 7771 8069
    X in | D-50829 Kln-Ossendorf http://berger-odenthal.de
    / \ Mail | -- No unannounced, large, binary attachments, please! --

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Ahem A Rivet's Shot on Thu Jan 13 21:54:34 2022
    On 13/01/2022 20:46, Ahem A Rivet's Shot wrote:
    On Thu, 13 Jan 2022 20:26:05 -0000
    "NY" <me@privacy.invalid> wrote:

    Sounds good. Which wireless standards support it, as an alternative to

    All the "wifi" and bluetooth standards are spread spectrum based.

    channels that are spaced more closely than the bandwidth of any given
    comms link (as you have with 2.4 GHz). Whenever I've run wifi spectrum
    analysis software, it's always shown me specific channel number for each

    More detail than you probably want to know:

    <http://webpages.eng.wayne.edu/~ad5781/ECECourses/ECE5620/Notes/Wi-Fi-Lecture.pdf>

    wifi network that is in range, and the number of channels either side
    that each network is using. Spread spectrum is completely different and
    as long as there are holes at irregular places in the spectrum, a spread
    spectrum will use it.

    TL;DR Wifi and bluetooth are spread spectrum using many very narrow channels spread around a fairly narrow space, this is why the effect of crowding APs too closely is a slowdown rather than a stop.

    No, that's not how its done. At least not for original wifi. OFDM is
    only used in later implementations..802.11a and g
    DSSS is used on the rests.

    Most routers support 802.11b,g and n. for 2,4Ghz
    And 802.11a, an and ac on 5GHz

    You should have read it. ADSL 'broad band' uses 'bins' like that. Wifi
    spread spectrum used DSSS - it multiplies it (convolutes) by a very
    high frequency pseudorandom code. What comes out is pseudorandom noise
    across the whole two or three channels. You convolute that again with
    the right code, and there is the wanted digital signal. Whereas any non
    random single frequency noise in the channel becomes convoluted to noise.

    Any other AP on nearby frequency will use a different code, so it will
    just become 'noise' once convoluted and deconvoluted by the wrong code.

    I was supposed to know this stuff, and I got as far as understanding the principle, but the bloody maths was beyond me.

    Frequency hopping is much slower than DSSS - Its an extra layer possibly
    on top of DSSS used to shift from the centre of one channel to another.

    It appears from your interesting PDF that bluetooth uses frequency
    hopping on much narrower channels - 1MHz instead of 22MHz. Without using
    DSSS

    But the interesting thing about 2.4GHz is that the ONLY restrictions
    legally placed on it are spectrum power and width. What you use within
    it can be almost anything



    --
    “It is hard to imagine a more stupid decision or more dangerous way of
    making decisions than by putting those decisions in the hands of people
    who pay no price for being wrong.”

    Thomas Sowell

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From druck@3:770/3 to The Natural Philosopher on Thu Jan 13 22:03:52 2022
    On 13/01/2022 09:41, The Natural Philosopher wrote:
    On 12/01/2022 21:15, druck wrote:
    On 12/01/2022 18:12, The Natural Philosopher wrote:
    I am still on 100Mbps ethernet, internally because for my little home
    setup its 'fast enough' and the 20 year old cable run its reliably

    There's no such thing as fast enough when it comes to networking!

    Ther is.

    if for example your network is faster than the server disk I/O then
    loading a file off that server wont get faster with extra network speed.

    That might be the case if you've got an old Raspberry Pi with a
    knackered SD card acting as a file server, but a Pi 4B with a USB3
    spinning rust drive does 100MB/s which is 8x faster than 100BaseT.
    Another of my Pi 4Bs with a SATA3 SSD easily saturates the gigabit Ethernet.

    ---druck

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Dennis Lee Bieber on Thu Jan 13 22:35:12 2022
    On 13/01/2022 21:41, Dennis Lee Bieber wrote:
    On Thu, 13 Jan 2022 20:26:05 -0000, "NY" <me@privacy.invalid> declaimed the following:

    "The Natural Philosopher" <tnp@invalid.invalid> wrote in message
    news:srpupi$ols$1@dont-email.me...

    I thought that wifi did have a defined bandwidth depending on the comms
    speed (ie which 802.11 standard it supports). I've always understood that
    channels 1, 6 and 11 are guaranteed not to overlap (at least for the earlier >> standards) and therefore you get no further benefit from using channels
    spaced more widely than 1, 6, 11, but that you get progressively more
    degradation as you move the channels closer than 1, 6, 11.

    But when you've got something like 6 neighbors all using "optimal" channels 1/6/11 -- you might be better off on channel 3/4 where you might
    not be getting channel usage congestion/collisions...



    The whole 2.4Ghz things is a messy delight of fun. I fly model planes on
    2.4Ghz and at least 4 modulation schemes are in place ...once at a model
    plane show there was a 'fly your own' period and 50+ models were in the air...well they didn't exactly interfere with each other, but the
    normally very slow data rates slowed to the point where people were
    losing control for a split second and seeing delays to command inputs.

    Another funny story is that one particular very well known 'brand' of transmitter went out with an individual code in its flash memory.
    Essentially a MAC code. In use you press a button on the receiver and it
    then 'pairs' with that MAC code...so different transmitters can coexist....


    ...until someone discovered that switching the transmitter on to check
    the battery charge state and then immediately switching it off crashed
    the NVRAM and erased the code...to zero. So all the transmitters ended
    up with that code.


    As far as wifi goes, even access points on the same channel will only
    really be an issue if the receiver close to one trying to receive the
    other. In DSSS the convolution code will sync with one or the other but
    not both.

    And I *think* that there is in general radio silence except when data is
    being transferred. Or SSIDs being transmitted

    Certainly when I ran my wifi scanner in a hospital last, there were
    about 20 channels of varying strength on the three main channels, and it
    all worked

    But I hate wifi. Bloody unreliable. The spark igniter on my central
    heating oil boiler reliably disconnects any wifi device in the house
    within 20 feet of it.
    My Pi-zero W maybe has 5ft reliable range through a wall, and the
    worst wifi chip in the world

    Oh dear. Its in the dining room and its managed to connect itself to
    the living room, 6 meters away...7Mbps instead of the kitchen

    Probably that one second power cut the other day..


    wlan0 IEEE 802.11 ESSID:"LivingRoom"
    Mode:Managed Frequency:2.432 GHz Access Point:
    74:4D:28:4A:21:86
    Bit Rate=7.2 Mb/s Tx-Power=31 dBm
    Retry short limit:7 RTS thr:off Fragment thr:off
    Power Management:on
    Link Quality=29/70 Signal level=-81 dBm
    Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
    Tx excessive retries:22 Invalid misc:0 Missed beacon:0

    let's see what rebooting gets me...

    iwconfig wlan0
    wlan0 IEEE 802.11 ESSID:"Kitchen"
    Mode:Managed Frequency:2.457 GHz Access Point:
    30:46:9A:A2:89:F6
    Bit Rate=57.7 Mb/s Tx-Power=31 dBm
    Retry short limit:7 RTS thr:off Fragment thr:off
    Power Management:on
    Link Quality=41/70 Signal level=-69 dBm
    Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
    Tx excessive retries:1 Invalid misc:0 Missed beacon:0

    Ah. That's better. 12 dB better. Still rubbish.

    I get -70dB and 40/70 quality in the laptop about 6 meters away from the
    same point and that manages 150Mbps....or thats what iwconfig says
    anyway., Realtek twin channel chip.





    --
    Renewable energy: Expensive solutions that don't work to a problem that
    doesn't exist instituted by self legalising protection rackets that
    don't protect, masquerading as public servants who don't serve the public.
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Laurenz Trossel@3:770/3 to Dennis Lee Bieber on Fri Jan 14 10:31:24 2022
    On 2022-01-13, Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:

    But when you've got something like 6 neighbors all using "optimal" channels 1/6/11 -- you might be better off on channel 3/4 where you might
    not be getting channel usage congestion/collisions...

    No. That's the worst option.

    Wifi networks on the same channel detect their presence and schedule their traffic so that only one transmitter is active at a time, reducing garbled packets and retransmissons.

    Wifi networks operating on adjacent, overlapping channels cause
    unpredictable random RFI, reducing performance for all users due to retransmissions. The same is true for a mix of 20Mhz/40Mhz networks.

    For best performance, switch to 5GHz on a frequency not in use by neighbors with enough spacing to enable 80+MHz channels.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From NY@3:770/3 to Laurenz Trossel on Fri Jan 14 12:12:08 2022
    "Laurenz Trossel" <me@example.invalid> wrote in message news:srrjdp$1opa$1@gioia.aioe.org...
    On 2022-01-13, Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:

    But when you've got something like 6 neighbors all using "optimal"
    channels 1/6/11 -- you might be better off on channel 3/4 where you might
    not be getting channel usage congestion/collisions...

    No. That's the worst option.

    Wifi networks on the same channel detect their presence and schedule their traffic so that only one transmitter is active at a time, reducing garbled packets and retransmissons.

    Wifi networks operating on adjacent, overlapping channels cause
    unpredictable random RFI, reducing performance for all users due to retransmissions. The same is true for a mix of 20Mhz/40Mhz networks.

    For best performance, switch to 5GHz on a frequency not in use by
    neighbors
    with enough spacing to enable 80+MHz channels.

    5 GHz is the best, but it does have two disadvantages:

    - the range is less because 5 GHz is attenuated more than 2.4 GHz for the
    same location of router and computer (ie the same distance and the same obstructions)

    - some older devices (my old laptop, our Foscam security cameras) don't
    support 5 GHz, so you may need 2.4 left on for compatibility

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Chris Green@3:770/3 to me@privacy.invalid on Fri Jan 14 12:44:32 2022
    NY <me@privacy.invalid> wrote:
    "Laurenz Trossel" <me@example.invalid> wrote in message news:srrjdp$1opa$1@gioia.aioe.org...
    On 2022-01-13, Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:

    But when you've got something like 6 neighbors all using "optimal"
    channels 1/6/11 -- you might be better off on channel 3/4 where you might >> not be getting channel usage congestion/collisions...

    No. That's the worst option.

    Wifi networks on the same channel detect their presence and schedule their traffic so that only one transmitter is active at a time, reducing garbled packets and retransmissons.

    Wifi networks operating on adjacent, overlapping channels cause unpredictable random RFI, reducing performance for all users due to retransmissions. The same is true for a mix of 20Mhz/40Mhz networks.

    For best performance, switch to 5GHz on a frequency not in use by
    neighbors
    with enough spacing to enable 80+MHz channels.

    5 GHz is the best, but it does have two disadvantages:

    - the range is less because 5 GHz is attenuated more than 2.4 GHz for the same location of router and computer (ie the same distance and the same obstructions)

    - some older devices (my old laptop, our Foscam security cameras) don't support 5 GHz, so you may need 2.4 left on for compatibility

    Nowhere in our house does 5Ghz offer any advantage, it's only if I put
    a client virtually on top of the router or AP (I have two which offer
    5Ghz) that it's any faster and I might as well use a wired connection
    in that case.

    Where I am using my laptop at the moment 2.4GHz gives me 300Mbs and
    5GHz gives me 180Mbs.

    We are lucky in that we have virtually no neighbours close enough to
    have any effect on our WiFi, I can only see one, faint, signal from
    our nearest neighbour who is across the road from us.

    --
    Chris Green
    ·

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From druck@3:770/3 to The Natural Philosopher on Fri Jan 14 13:36:38 2022
    On 13/01/2022 22:35, The Natural Philosopher wrote:
    But I hate wifi. Bloody unreliable. The spark igniter on my central
    heating oil  boiler reliably disconnects any wifi device in the house within 20 feet of it.
    My Pi-zero W  maybe has 5ft reliable  range through a wall, and the
    worst wifi chip in the world

    Oh dear. Its in the dining room and  its managed to connect itself to
    the living room, 6 meters away...7Mbps instead of the kitchen

    The Pi-zero W's WiFi is fine for a single antenna of that size - as long
    as it knows what to connect to.

    If you are using multiple consumer access points you are always going to
    get issues like this. Proper managed WiFi can be set up to ensure a
    device connects to the most appropriate access point.

    ---druck

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to druck on Fri Jan 14 13:48:54 2022
    On 14/01/2022 13:36, druck wrote:
    On 13/01/2022 22:35, The Natural Philosopher wrote:
    But I hate wifi. Bloody unreliable. The spark igniter on my central
    heating oil  boiler reliably disconnects any wifi device in the house
    within 20 feet of it.
    My Pi-zero W  maybe has 5ft reliable  range through a wall, and the
    worst wifi chip in the world

    Oh dear. Its in the dining room and  its managed to connect itself to
    the living room, 6 meters away...7Mbps instead of the kitchen

    The Pi-zero W's WiFi is fine for a single antenna of that size - as long
    as it knows what to connect to.

    If you are using multiple consumer access points you are always going to
    get issues like this. Proper managed WiFi can be set up to ensure a
    device connects to the most appropriate access point.

    The problem is its set up to try the kitchen first, then the living room

    But, under power cut conditions the kitchen - a repurposed Netgear ADSL
    router - takes longer to boot than the Pi..

    Ergo it found the nearest and best access point it could.

    The problem is that i dont know how to make it switch to a strionger one
    if there is one, later.





    --
    "Anyone who believes that the laws of physics are mere social
    conventions is invited to try transgressing those conventions from the
    windows of my apartment. (I live on the twenty-first floor.) "

    Alan Sokal

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Chris Green on Fri Jan 14 13:52:04 2022
    On 14/01/2022 12:44, Chris Green wrote:
    NY <me@privacy.invalid> wrote:
    "Laurenz Trossel" <me@example.invalid> wrote in message
    news:srrjdp$1opa$1@gioia.aioe.org...
    On 2022-01-13, Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:

    But when you've got something like 6 neighbors all using "optimal"
    channels 1/6/11 -- you might be better off on channel 3/4 where you might >>>> not be getting channel usage congestion/collisions...

    No. That's the worst option.

    Wifi networks on the same channel detect their presence and schedule their >>> traffic so that only one transmitter is active at a time, reducing garbled >>> packets and retransmissons.

    Wifi networks operating on adjacent, overlapping channels cause
    unpredictable random RFI, reducing performance for all users due to
    retransmissions. The same is true for a mix of 20Mhz/40Mhz networks.

    For best performance, switch to 5GHz on a frequency not in use by
    neighbors
    with enough spacing to enable 80+MHz channels.

    5 GHz is the best, but it does have two disadvantages:

    - the range is less because 5 GHz is attenuated more than 2.4 GHz for the
    same location of router and computer (ie the same distance and the same
    obstructions)

    - some older devices (my old laptop, our Foscam security cameras) don't
    support 5 GHz, so you may need 2.4 left on for compatibility

    Nowhere in our house does 5Ghz offer any advantage, it's only if I put
    a client virtually on top of the router or AP (I have two which offer
    5Ghz) that it's any faster and I might as well use a wired connection
    in that case.

    Where I am using my laptop at the moment 2.4GHz gives me 300Mbs and
    5GHz gives me 180Mbs.

    We are lucky in that we have virtually no neighbours close enough to
    have any effect on our WiFi, I can only see one, faint, signal from
    our nearest neighbour who is across the road from us.

    My nearest neighbour is 200+ yards away.

    All I can see are my three access points, one of which is almost
    useless, and came with the router, which is in a room with foil backed plasterboard walls.

    It has been quite a struggle to find good places for the access points,
    based on where people like to use WiFi.


    --
    "Anyone who believes that the laws of physics are mere social
    conventions is invited to try transgressing those conventions from the
    windows of my apartment. (I live on the twenty-first floor.) "

    Alan Sokal

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Chris Green@3:770/3 to druck on Fri Jan 14 14:24:00 2022
    druck <news@druck.org.uk> wrote:
    On 13/01/2022 22:35, The Natural Philosopher wrote:
    But I hate wifi. Bloody unreliable. The spark igniter on my central
    heating oil  boiler reliably disconnects any wifi device in the house within 20 feet of it.
    My Pi-zero W  maybe has 5ft reliable  range through a wall, and the
    worst wifi chip in the world

    Oh dear. Its in the dining room and  its managed to connect itself to
    the living room, 6 meters away...7Mbps instead of the kitchen

    The Pi-zero W's WiFi is fine for a single antenna of that size - as long
    as it knows what to connect to.

    If you are using multiple consumer access points you are always going to
    get issues like this. Proper managed WiFi can be set up to ensure a
    device connects to the most appropriate access point.

    Only if "a device" cooperates. Modern devices *should* have the latest
    WiFi standards updates in them so that they understand and usew the
    hints given by mesh systems. However it is always down to the client
    to choose which AP to use and older (and other badly configured)
    clients may well not choose the right AP or move when sensible.

    --
    Chris Green
    ·

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From druck@3:770/3 to Chris Green on Fri Jan 14 21:29:18 2022
    On 14/01/2022 14:24, Chris Green wrote:
    druck <news@druck.org.uk> wrote:
    If you are using multiple consumer access points you are always going to
    get issues like this. Proper managed WiFi can be set up to ensure a
    device connects to the most appropriate access point.

    Only if "a device" cooperates. Modern devices *should* have the latest
    WiFi standards updates in them so that they understand and usew the
    hints given by mesh systems. However it is always down to the client
    to choose which AP to use and older (and other badly configured)
    clients may well not choose the right AP or move when sensible.

    An actively managed system can send a drop to a device on an undesirable
    access point, which forces it to re-establish a connection to an access
    point with a stronger system.

    ---druck

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Chris Green@3:770/3 to druck on Fri Jan 14 21:36:04 2022
    druck <news@druck.org.uk> wrote:
    On 14/01/2022 14:24, Chris Green wrote:
    druck <news@druck.org.uk> wrote:
    If you are using multiple consumer access points you are always going to >> get issues like this. Proper managed WiFi can be set up to ensure a
    device connects to the most appropriate access point.

    Only if "a device" cooperates. Modern devices *should* have the latest
    WiFi standards updates in them so that they understand and usew the
    hints given by mesh systems. However it is always down to the client
    to choose which AP to use and older (and other badly configured)
    clients may well not choose the right AP or move when sensible.

    An actively managed system can send a drop to a device on an undesirable access point, which forces it to re-establish a connection to an access
    point with a stronger system.

    Yes, but dropping the connection will break whatever is going on. lost
    phone conversation, broken streaming, whatever. It's an absolute last
    resort to drop the connection.

    --
    Chris Green
    ·

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From druck@3:770/3 to Chris Green on Mon Jan 17 22:07:28 2022
    On 14/01/2022 21:36, Chris Green wrote:
    druck <news@druck.org.uk> wrote:
    On 14/01/2022 14:24, Chris Green wrote:
    druck <news@druck.org.uk> wrote:
    If you are using multiple consumer access points you are always going to >>>> get issues like this. Proper managed WiFi can be set up to ensure a
    device connects to the most appropriate access point.

    Only if "a device" cooperates. Modern devices *should* have the latest
    WiFi standards updates in them so that they understand and usew the
    hints given by mesh systems. However it is always down to the client
    to choose which AP to use and older (and other badly configured)
    clients may well not choose the right AP or move when sensible.

    An actively managed system can send a drop to a device on an undesirable
    access point, which forces it to re-establish a connection to an access
    point with a stronger system.

    Yes, but dropping the connection will break whatever is going on. lost
    phone conversation, broken streaming, whatever. It's an absolute last
    resort to drop the connection.

    It's usually done at the point the device first connects to the
    unsuitable access point, so nothing is going on then, and it just
    appears to take slight longer to get a WiFi signal.

    ---druck
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Chris Green@3:770/3 to druck on Tue Jan 18 09:19:12 2022
    druck <news@druck.org.uk> wrote:
    On 14/01/2022 21:36, Chris Green wrote:
    druck <news@druck.org.uk> wrote:
    On 14/01/2022 14:24, Chris Green wrote:
    druck <news@druck.org.uk> wrote:
    If you are using multiple consumer access points you are always going to >>>> get issues like this. Proper managed WiFi can be set up to ensure a
    device connects to the most appropriate access point.

    Only if "a device" cooperates. Modern devices *should* have the latest >>> WiFi standards updates in them so that they understand and usew the
    hints given by mesh systems. However it is always down to the client
    to choose which AP to use and older (and other badly configured)
    clients may well not choose the right AP or move when sensible.

    An actively managed system can send a drop to a device on an undesirable >> access point, which forces it to re-establish a connection to an access
    point with a stronger system.

    Yes, but dropping the connection will break whatever is going on. lost phone conversation, broken streaming, whatever. It's an absolute last resort to drop the connection.

    It's usually done at the point the device first connects to the
    unsuitable access point, so nothing is going on then, and it just
    appears to take slight longer to get a WiFi signal.

    That assumes you have a client that does a "first connect" after not
    being used for a while. I'm much more familiar with the way my laptop
    does things and that simply never disconnects unless I explicitly tell
    it to. Thus there isn't a time when "the device first connects", it has
    been connected all night and I've just walked through from the lounge
    where I used it last night to the breakfast room where I'm using it now.

    --
    Chris Green
    ·
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)