Rasberry Pi 4 Model B keyboards gone wild

This is one of the strangest things that has happend to me ever. I have installed on my raspbery pi 4b both ext4 and squashfs latest builds and for some reason when i plug any USB keyboard to access shell, what i write is not what the system interprets.

I have done a photo because i dont have options to access via SSH atm (more info in the bottom)

This is the first time I install a RPI with OpenWRT. I've done multiple routers in the past. I'm using latest SNAPSHOT from firmware selector

Another super-strange thing I connect my PC straight to the ethernet port from the Raspi, and it doesnt see each other (I'm assuming 192.168.1.1 for Pi because I cannot ifconfig)

I config my computer with 192.168.1.100 and gw 192.168.1.1 for the test but nothing. DHCP is not working either. Maybe I need a crossed wire for this connection, and I dont have a switch either to test.

I can't believe I'm finding so many hassles. The best part is that I connected at some point the Pi to the regular network (I have it in another subnet) with the PC also connected to the same network, and I was able to SSH in, so the Pi networking is working 100%. And the keyboard is working also, because in raspbian I dont find any issues. I've tried two keyboards just in case was some weird driver issue.

I'm out of ideas by now.

Quick test with another keyboard.
Although I suspect something else is wrong, since you cannot also access the router and DHCP is not working.

There are STABLE versions, I don't see why you'd go for the SNAPSHOT.

I tried 2 keyboards. Maybe a 3rd could do the trick but I don't have one handy rn

I will reflash with a stable version maybe a 22 instead of a 23 just to test. Theorically DHCP should work connecting my PC straight to the single ethernet port from the Pi? I read somewhere that the ethernet port from PI is a lan port and generally people set Pi from an external device that is the wan port.

This is driving me nuts, how can it be some complex compared to any router so far, given how easy is to setup a Rpi.

Right, the only ethernet port is assigned to lan interface, hence it should offer dhcp and listen to 192.168.1.1

At some point I started considering that raspi needed a crossover cable to connect to my PC, since the only moment I was able to connect (I have not been able to replicate it after that) was when I connected the Raspi to another OpenWRT router (in a different network, 192.168.100.0/24). I'm not even sure how the connect was even possible, it seems that some routes were stablished somehow not sure how, I did not touch anything nor modified the network.

I think that any NIC since 20 years ago supports auto-mdi-x, so cross cable shouldn't be an issue.

1 Like

https://github.com/openwrt/openwrt/issues/15125 related? For that user 23.05.3 works so you could just flash that, don't use SNAPSHOT.

1 Like

I would check if the SD card is failing. I've seen SD cards that worked just enough to flash and boot an operating system, but fail when doing anything beyond that. This produced completely unpredictable and bizarre symptoms that went away when I used a new SD card from a reputable vendor.

I've found the time to diagnose the problem, and this was the exact issue. SNAPSHOT is throwing a misbehavior with the keyboard

Maybe I could config in the past, because I downloaded the firmware from the raspberry wikipage (which happend to be a 23.05.3) and then for some reason I started downloading the SNAPSHOT image from the firmware selector.

Nex time use the Firmware Selector Drop down on the right and pick the firmware you want to use.

RPi's, in general, do not like additional devices on a previously used port as it assigns a USB address to the driver of the first device use and can lead to problems so I suggest you use a Logitech mouse and keyboard with a unifying receiver or a keyboard touchpad combo and plan out which device(s) will get which port in the final build.

Or you can use a USB hub but same rules: one device for each port. The address a device is assigned will be unique to the hub.

I, also, suggest you know what drivers you will want for any periphials and bake them into the firmware build by editing them in the Customize installed packages and/or first boot script, then add each device with only a keyboard for first boot, rebooting, and adding the rest one at a time, with a reboot between each additional added device. I suggest you get an Industrial Grade sd card (their controllers have many features including built in wear leveling and much more over-provising; among other life extending features.
Lastly, ensure you have the latest bootloader, as mentioned on the OpenWrt Pi4 device page.

I've taken a close look at this since snapshot completely breaks the UART console on Raspberry Pi. I've made a pull request that fixes this:

It turns out the fix is trivial: just swap the order of the two console options in cmdline.txt, so that console=tty1 appears after console=serial0,115200.

5 Likes

Is that specific to the OP?

Because RPis DO NOT LIKE usb plug and play: it, seems, to cause issues I have found go away if the USB device address does not need to keep multiple devices.

Nice, that is what was making the issue

Thanks for the work here. Just found out my RPi5B's keyboard was jacked AF but your commit fixed it.

Can't say I've experienced USB hotplug issues on Raspberry Pis, at least as far as the kernel is concerned. If I recall correctly USB device addresses are not "sticky" on Linux. Meaning if I unplug and plug in the same device, even on the same port and hub, the kernel assigns a different device address.

Now what some userspace program does with USB devices arriving and leaving at arbitrary times is a different question. Some tools like tio can gracefully handle USB serial disconnects and reconnects, others not so much.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.