On Wed, 25 Nov 2020 19:18:43 +0300 Reco <recovery...@enotuniq.net> wrote:
> On Wed, Nov 25, 2020 at 10:31:55AM -0500, Celejar wrote: > > On Wed, 25 Nov 2020 17:43:00 +0300 > > Reco <recovery...@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 <recovery...@enotuniq.net> wrote: > > > > > > > > > On Tue, Nov 24, 2020 at 03:06:59PM -0800, pe...@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. Thanks for the detailed explanation, although I'm afraid that it's still a little above my head. So when you referred above to a "low-quality kernel module," you weren't referring to the linux kernel, but something that TP-Link installs onto their products? Celejar
