Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #229068
| From | Reco <recoverym4n@enotuniq.net> |
|---|---|
| Newsgroups | linux.debian.user |
| Subject | Re: Instructions for command line usage of WiFi. |
| Date | 2020-11-25 17:20 +0100 |
| Message-ID | <Bf5Gq-1Bc-9@gated-at.bofh.it> (permalink) |
| References | (2 earlier) <BeQem-vz-1@gated-at.bofh.it> <BeXIS-57t-7@gated-at.bofh.it> <Bf3Oi-ta-9@gated-at.bofh.it> <Bf4hk-D3-7@gated-at.bofh.it> <Bf53H-198-3@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Wed, Nov 25, 2020 at 10:31:55AM -0500, Celejar wrote: > On Wed, 25 Nov 2020 17:43:00 +0300 > Reco <recoverym4n@enotuniq.net> wrote: > > > On Wed, Nov 25, 2020 at 09:19:08AM -0500, Celejar wrote: > > > On Wed, 25 Nov 2020 10:42:59 +0300 > > > Reco <recoverym4n@enotuniq.net> wrote: > > > > > > > On Tue, Nov 24, 2020 at 03:06:59PM -0800, peter@easthope.ca wrote: > > > > > This is the only oddity evident after ifup wlxa0f3c10a28f7. > > > > > > > > > > DHCPDISCOVER on wlxa0f3c10a28f7 to 255.255.255.255 port 67 interval 3 > > > > > send_packet: No buffer space available > > > > > dhclient.c:2445: Failed to send 300 byte long packet over wlxa0f3c10a28f7 interface. > > > > > > > > > > Nevertheless, after a few more lines from DHCP the link works. > > > > > Any ideas about buffer space? > > > > > > > > The kernel has no free RAM to queue a packet or that Tp-Link device > > > > you're is using low-quality kernel module. Happens with Tp-Link, but > > > > > > With TP-Link? Aren't they just using other manufacturers' chipsets? > > > > The hardware is definitely OEM'ed. The firmware is most likely theirs. > > Really? I thought that network drivers load firmware based solely on > the chipset. It's more complicated than this. For instance, to identify a NIC chip you need something that responds to said identification. To put it simple, to load a firmware you need something to accept it. Some chips (ESP, nRF to name a few) allow you to write a firmware, but can hide lower-level functions like actual frame sending (i.e. - blobs in SDK). I.e. you provide a chip a tiny, yet complete OS, because otherwise all you have a chip that cannot even boot. From the host POV you just put some bits on a appropriate bus and hope that the other side is something you expect it to be. An example - [1]. Some chips (Broadcom, Realtek or Intel, for instance), have an OS part baked-in (or, very rarely - stored at EEPROM), and payload (i.e. application-level software) needs to be loaded by host. And that my "firmware" statement was referred to a part that's baked-in, not a blob from linux-firmware. After all, A0:F3:C1 in that NIC above is Tp-Link, not Realtek. Reco [1] https://github.com/espressif/esp-hosted
Back to linux.debian.user | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Instructions for command line usage of WiFi. peter@easthope.ca - 2020-11-06 01:00 +0100
Re: Instructions for command line usage of WiFi. Reco <recoverym4n@enotuniq.net> - 2020-11-06 06:30 +0100
Re: Instructions for command line usage of WiFi. peter@easthope.ca - 2020-11-15 23:00 +0100
Re: Instructions for command line usage of WiFi. Stefan Monnier <monnier@iro.umontreal.ca> - 2020-11-15 23:10 +0100
Re: Instructions for command line usage of WiFi. David Wright <deblis@lionunicorn.co.uk> - 2020-11-17 16:40 +0100
Re: Instructions for command line usage of WiFi. peter@easthope.ca - 2020-11-25 00:50 +0100
Re: Instructions for command line usage of WiFi. Reco <recoverym4n@enotuniq.net> - 2020-11-25 08:50 +0100
Re: Instructions for command line usage of WiFi. Celejar <celejar@gmail.com> - 2020-11-25 15:20 +0100
Re: Instructions for command line usage of WiFi. Reco <recoverym4n@enotuniq.net> - 2020-11-25 15:50 +0100
Re: Instructions for command line usage of WiFi. Celejar <celejar@gmail.com> - 2020-11-25 16:40 +0100
Re: Instructions for command line usage of WiFi. Reco <recoverym4n@enotuniq.net> - 2020-11-25 17:20 +0100
Re: Instructions for command line usage of WiFi. Celejar <celejar@gmail.com> - 2020-11-25 19:10 +0100
Re: Instructions for command line usage of WiFi. peter@easthope.ca - 2020-11-27 01:00 +0100
Re: Instructions for command line usage of WiFi. Gene Heskett <gheskett@shentel.net> - 2020-11-27 02:10 +0100
Re: Instructions for command line usage of WiFi. peter@easthope.ca - 2020-11-27 17:10 +0100
Re: Instructions for command line usage of WiFi. Reco <recoverym4n@enotuniq.net> - 2020-11-27 07:40 +0100
Re: Instructions for command line usage of WiFi. peter@easthope.ca - 2020-11-27 18:40 +0100
Re: Instructions for command line usage of WiFi. Dan Ritter <dsr@randomstring.org> - 2020-11-27 18:50 +0100
Re: Instructions for command line usage of WiFi. Reco <recoverym4n@enotuniq.net> - 2020-11-27 19:10 +0100
Re: Instructions for command line usage of WiFi. peter@easthope.ca - 2020-11-30 04:10 +0100
Re: Instructions for command line usage of WiFi. Doug McGarrett <dmcgarrett@optonline.net> - 2020-11-30 05:50 +0100
Re: Instructions for command line usage of WiFi. ghe2001 <ghe2001@protonmail.com> - 2020-11-30 07:10 +0100
Re: Instructions for command line usage of WiFi. Reco <recoverym4n@enotuniq.net> - 2020-11-30 09:50 +0100
Use of external connectors on a Sharp Mebius laptop; was Re: Instructions for command line usage of WiFi. peter@easthope.ca - 2020-12-01 03:10 +0100
Re: Instructions for command line usage of WiFi. Gene Heskett <gheskett@shentel.net> - 2020-11-27 22:00 +0100
Re: Instructions for command line usage of WiFi. Richard Hector <richard@walnut.gen.nz> - 2020-11-29 11:40 +0100
Re: Instructions for command line usage of WiFi. Gene Heskett <gheskett@shentel.net> - 2020-11-29 13:40 +0100
Instructions for command line usage of WiFi. peter@easthope.ca - 2020-11-27 04:50 +0100
Re: Instructions for command line usage of WiFi. Wim <factotum_muth@web.de> - 2020-11-29 20:40 +0100
Graphical environment; was, Re: Instructions for command line usage of WiFi. peter@easthope.ca - 2020-12-01 15:50 +0100
csiph-web