I have an embedded computer that is running Linux 3.4, and there is not a way for me to upgrade to 4.x.y at the moment unfortunately.
I have compiled g_ether as a kernel module using the following configuration options:
CONFIG_USB_ETH=m
CONFIG_USB_ETH_RNDIS=y
The module compiles fine and I can load it once the system has booted with no issues:
[ 7.160000] DWC_otg: dwc_udc_start: g_ether
[ 7.168000] DWC_otg: bind to driver g_ether
[ 7.176000] DWC_otg: dwc_otg_pcd_alloc_request(e30171a4,208)
[ 7.184000] g_ether gadget: using random self ethernet address
[ 7.196000] usb0: MAC 52:e9:07:c2:0f:23
[ 7.204000] usb0: HOST MAC 82:cf:ce:fa:44:18
[ 7.212000] rndis_bind
[ 7.224000] DWC_otg: dwc_otg_pcd_alloc_request(e30171ec,208)
[ 7.232000] rndis_register: configNr = 0
[ 7.236000] rndis_set_param_medium: 0 0
[ 7.244000] DWC_otg: dwc_otg_pcd_alloc_request(e30171ec,208)
[ 7.252000] g_ether gadget: Ethernet Gadget, version: Memorial Day 2008
[ 7.264000] g_ether gadget: g_ether ready
[ 7.268000] DWC_otg: dwc_udc_start: registered gadget driver 'g_ether'
My goal is to connect this embedded computer to a Windows computer. When I connect the embedded computer, Windows initially shows the "device" in the Device Manager as working properly and then updates to show that it is not working with the error:
This device cannot start. (Code 10)
FWIW I have tried several different drivers on the Windows side, including the linux.inf referenced in the Linux USG Gadget documentation, several of the built-in drivers, and one driver I found on a forum.
From the Linux side, when I plug in the USB cord, I see the following output:
Aug 29 05:13:54 dot-8f2wktlxah kernel: [ 31.840000] g_ether gadget: init rndis
Aug 29 05:13:54 dot-8f2wktlxah kernel: [ 31.840000] g_ether gadget: RNDIS RX/TX early activation ...
Aug 29 05:13:54 dot-8f2wktlxah kernel: [ 32.116000] usb0: qlen 10
Aug 29 05:13:56 dot-8f2wktlxah kernel: [ 34.128000] g_ether gadget: rndis req21.00 v0000 i0000 l24
Aug 29 05:13:56 dot-8f2wktlxah kernel: [ 34.540000] g_ether gadget: rndis reqa1.01 v0000 i0000 l4096
This corresponds on the Windows side (via USBPcap):
1226 29734.081932 host 2.1.0 USBCOM 36 SEND ENCAPSULATED COMMAND Request
1227 29735.362932 2.1.0 host USBCOM 52 SEND ENCAPSULATED COMMAND Response
1228 29735.362932 2.1.0 host USB 28 GET STATUS Status
1229 29735.810932 2.1.2 host USBCOM 35 NETWORK CONNECTION
1230 29735.810932 host 2.1.0 USBCOM 36 GET ENCAPSULATED RESPONSE Request
The rndis req21 on the Linux side corresponds to the SEND ENCAPSULATED COMMAND on the Windows side, and the same is true for the rndis reqa1 and GET ENCAPSULATED RESPONSE.
There is no other output on either after those last response/requests.
I understand that Linux 3.4 is very out of date, but I don't have the option to upgrade since this is an embedded computer and thus I am beholden to the chip-maker to provide an update.
Has anyone successfully used the g_ether kernel module with Windows 7/8 and Linux 3.4, or know why these request/responses seem to just stop after that last GET ENCAPSULATED RESPONSE?
Related
I was wondering if anyone knows why chromium based browsers trigger direct rendering manager on startup on Linux whereas Firefox for example doesn't seem to do that? This is what I see when starting chromium:
Dec 19 11:02:30 hp kernel: [drm] PCIE GART of 256M enabled (table at 0x000000F400000000).
Dec 19 11:02:31 hp kernel: [drm] UVD and UVD ENC initialized successfully.
Dec 19 11:02:31 hp kernel: [drm] VCE initialized successfully.
I bought a RFlink Gateway from Nodo-shop.nl, the the RFLink 433.42 Somfy RTS version, to use with Domoticz on a RPI. I had Nodo to solder the components of my Rflink, so there should not be any problem on this end :)
I connected it to my MacbookAir, and followed the instructions on Domoticz wiki to upload the firmware into the RFlink. It apparently uploaded the firmware successfully.
Then I updated and upgraded my RPI (Linux raspberrypi 5.4.79-v7+ #1373 SMP Mon Nov 23 13:22:33 GMT 2020 armv7l GNU/Linux) and hooked it up to my Raspberry Pi 3 .
I tried to identify the port with Dmesg. If the Arduino Mega is detected, I cannot see the ttyAMCO or ttyUSB everyone is referring to in various posts.
Here is the output of the dmesg command:
[3902580.423329] usb 1-1.1.2: new full-speed USB device number 9 using dwc_otg [3902580.568650] usb 1-1.1.2: New USB device found, idVendor=2341, idProduct=0042, bcdDevice= 0.01 [3902580.568671] usb 1-1.1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=220 [3902580.568685] usb 1-1.1.2: Manufacturer: Arduino (www.arduino.cc) [3902580.568699] usb 1-1.1.2: SerialNumber: 55037313237351714260
I also tried to look for the port using this command ls /dev | grep tty*. I can only see these ports : ttyXX, ttyAMA0 and ttyprintk. But no sign of the port of my RFlink Gateway.
When I use this command lsusb, it shows it recognizes the Arduino:
Bus 001 Device 009: ID 2341:0042 Arduino SA Mega 2560 R3 (CDC ACM).
I read tons of posts on the internet but I did not find any answer to my problem.
I even bought a power supply for my Arduino Mega as some wrote that it may not get enough power from the RPI's USB. But I still have the same problem...
What I'm not doing right ? Or what am I not looking at ?
Thank you for your help
Sorry, bit late but it might be useful to someone else...
It might well be the /dev/ttyAMA0 you found - it depends what else you've got on there.
listing by id should identify it definitively though:
$ ls -l /dev/serial/by-id/
total 0
lrwxrwxrwx 1 root root 13 Mar 18 2021 usb-0658_0200_12345678-9012-3456-7890-123456789012-if00 -> ../../ttyACM1
lrwxrwxrwx 1 root root 13 Mar 18 2021 usb-Arduino__www.arduino.cc__0042_55639313533351509150-if00 -> ../../ttyACM0
So, in my case it's on /dev/ttyACM0.
If you've got multiple USB serial adapters, reboot the pi with them all plugged in to get the default mapping (I've seen hotplugged AMA0 and AMA1 swap after a reboot).
I have a RT5350F router device (Hardware is almost the same as Nexx WT1520). It used to run Zyxel Keenetic 4G II firmware, and now I decided to reflash OpenWRT to it.
I tried a lot of versions, and all of them don't boot any further than this:
U-Boot 1.1.3 (Apr 11 2013 - 00:10:51)
Board: Ralink APSoC DRAM: 16 MB
relocate_code Pointer at: 80fb4000
spi_wait_nsec: 42
spi device id: c2 20 16 c2 20 (2016c220)
find flash: MX25L3205D
raspi_read: from:30000 len:1000
.*** Warning - bad CRC, using default environment
============================================
Ralink UBoot Version: 3.6.0.0
--------------------------------------------
ASIC 5350_MP (Port5<->None)
DRAM_CONF_FROM: Boot-Strapping
DRAM_TYPE: SDRAM
DRAM_SIZE: 128 Mbits
DRAM_WIDTH: 16 bits
DRAM_TOTAL_WIDTH: 16 bits
TOTAL_MEMORY_SIZE: 16 MBytes
Flash component: SPI Flash
Date:Apr 11 2013 Time:00:10:51
============================================
icache: sets:256, ways:4, linesz:32 ,total:32768
dcache: sets:128, ways:4, linesz:32 ,total:16384
##### The CPU freq = 360 MHZ ####
estimate memory size =16 Mbytes
Please choose the operation:
1: Load system code to SDRAM via TFTP.
2: Load system code then write to Flash via TFTP.
3: Boot system code via Flash (default).
4: Entr boot command line interface.
7: Load Boot Loader code then write to Flash via Serial.
9: Load Boot Loader code then write to Flash via TFTP. 0
3: System Boot system code via Flash.
## Booting image at bc050000 ...
raspi_read: from:50000 len:40
. Image Name: MIPS OpenWrt Linux-3.18.45
Created: 2017-03-05 12:30:01 UTC
Image Type: MIPS Linux Kernel Image (lzma compressed)
Data Size: 1087633 Bytes = 1 MB
Load Address: 80000000
Entry Point: 80000000
raspi_read: from:50040 len:109891
................. Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
No initrd
## Transferring control to Linux (at address 80000000) ...
## Giving linux memsize in MB, 16
Starting kernel ...
[ 0.000000] Linux version 3.18.45 (wayfarer#VirtualBox) (gcc version 4.8.3 (O penWrt/Linaro GCC 4.8-2014.04 r49389) ) #3 Sun Mar 5 14:29:13 EET 2017
[ 0.000000] SoC Type: Ralink RT5350 id:1 rev:3
[ 0.000000] bootconsole [early0] enabled
[ 0.000000] CPU0 revision is: 0001964c (MIPS 24KEc)
[ 0.000000] MIPS: machine is Nexx WT1520
[ 0.000000] Determined physical RAM map:
[ 0.000000] memory: 02000000 # 00000000 (usable)
[ 0.000000] Initrd not found or empty - disabling initrd
[ 0.000000] Zone ranges:
[ 0.000000] Normal [mem 0x00000000-0x01ffffff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x00000000-0x01ffffff]
[ 0.000000] Initmem setup node 0 [mem 0x00000000-0x01ffffff]
I reflashed U-boot as well, which didn't really help.
Some other OpenWRT firmwares boot, but crash right away, saying "Not enough RAM".
I use dual boot for linux/windows.
I'm trying to install wireless driver on Debian_3.16-0.bpo.3-amd64 (bpo is for backport) Wheezy for my MSI laptop (MSI GP60 2PE Leopard).
I made lspci -nn to find reference about my network controller:
Network controller [0280]: Intel Corporation Device [8086:08b3] (rev 83)
So on the website of linux Wireless
My driver must be this one : iwlwifi
I installed it,
apt-get install firmware-iwlwifi
modprobe iwlwifi
but it doesn't work...
During the boot, there are some errors :
Intel(R) Wireless WiFi driver for Linux, in-tree:
[ 4.847284] Copyright(c) 2003- 2014 Intel Corporation
[ 4.847449] iwlwifi 0000:05:00.0: irq 50 for MSI/MSI-X
[ 4.877181] mei_me 0000:00:16.0: irq 51 for MSI/MSI-X
[ 4.923823] iwlwifi 0000:05:00.0: firmware: failed to load iwlwifi-3160-9.ucode (-2)
[ 4.923877] iwlwifi 0000:05:00.0: Direct firmware load failed with error -2
[ 4.923878] iwlwifi 0000:05:00.0: Falling back to user helper
[ 4.940971] Bluetooth: Core ver 2.19
[ 4.940987] NET: Registered protocol family 31
[ 4.940988] Bluetooth: HCI device and connection manager initialized
[ 4.940996] Bluetooth: HCI socket layer initialized
[ 4.940998] Bluetooth: L2CAP socket layer initialized
[ 4.941006] Bluetooth: SCO socket layer initialized
If this can help you, I made modinfo iwlwifi and this is the output :
http://pastebin.com/s8ycnBwu
To make sure that Aptitude package firmware-iwlwifi contains drivers for your device, lookup drivers from chip manufactor web sites...
I recommend to compare Kernel version and intel iwlwifi driver version, from: http://www.intel.com/support/wireless/wlan/sb/CS-034398.htm
and how to guides can be found on: http://wireless.kernel.org/en/users/Drivers/iwlwifi
With these links I hope you can find your own iwlwifi package, if it's supported.
You can check chipset via Windows Device Management...
My background is mostly Windows programming in C and C++. Recently I've had the chance to work with some embedded Linux systems also, but I'm still new at this.
Right now I'm working on a utility for Openwrt that needs to react to network and system events that occur during normal operation.
I've been able to use Hotplug for some events, but others still elude me. I can parse the output of the system log using logread, but that seems primitive and hackish.
In particular I'd like to get a callback similar to what hotplug does for some of the 'kern.info kernel' and 'daemon.info' events. For example:
Mar 31 19:42:32 OpenWrt kern.info kernel: [ 369.540000] device wlan0 left promiscuous mode
Mar 31 19:42:32 OpenWrt kern.info kernel: [ 369.540000] br-lan: port 2(wlan0) entered disabled state
Mar 31 19:42:32 OpenWrt kern.info kernel: [ 369.730000] device wlan1 left promiscuous mode
Mar 31 19:42:32 OpenWrt kern.info kernel: [ 369.730000] br-lan: port 3(wlan1) entered disabled state
Mar 31 19:42:34 OpenWrt kern.info kernel: [ 371.360000] device wlan0 entered promiscuous mode
Mar 31 19:45:56 OpenWrt daemon.info hostapd: wlan0: STA 04:f7:e4:00:00:00 IEEE 802.11: authenticated
Mar 31 19:45:56 OpenWrt daemon.info hostapd: wlan0: STA 04:f7:e4:00:00:00 IEEE 802.11: associated (aid 1)
Mar 31 19:45:56 OpenWrt daemon.info hostapd: wlan0: STA 04:f7:e4:00:00:00 WPA: pairwise key handshake completed (WPA)
Mar 31 19:45:56 OpenWrt daemon.info hostapd: wlan0: STA 04:f7:e4:00:00:00 WPA: group key handshake completed (WPA)
Mar 31 19:45:56 OpenWrt daemon.info dnsmasq-dhcp[5005]: DHCPREQUEST(br-lan) 10.1.1.51 04:f7:e4:00:00:00
Mar 31 19:45:56 OpenWrt daemon.info dnsmasq-dhcp[5005]: DHCPNAK(br-lan) 10.1.1.51 04:f7:e4:00:00:00 wrong network
Mar 31 19:46:00 OpenWrt daemon.info dnsmasq-dhcp[5005]: DHCPDISCOVER(br-lan) 04:f7:e4:00:00:00
Mar 31 19:46:00 OpenWrt daemon.info dnsmasq-dhcp[5005]: DHCPOFFER(br-lan) 192.168.1.198 04:f7:e4:1c:09:00
Mar 31 19:46:00 OpenWrt daemon.info dnsmasq-dhcp[5005]: DHCPDISCOVER(br-lan) 04:f7:e4:1c:09:00
Mar 31 19:46:00 OpenWrt daemon.info dnsmasq-dhcp[5005]: DHCPOFFER(br-lan) 192.168.1.198 04:f7:e4:1c:09:00
Mar 31 19:46:01 OpenWrt daemon.info dnsmasq-dhcp[5005]: DHCPREQUEST(br-lan) 192.168.1.198 04:f7:e4:1c:09:00
Mar 31 19:46:01 OpenWrt daemon.info dnsmasq-dhcp[5005]: DHCPACK(br-lan) 192.168.1.198 04:f7:e4:1c:09:00 My-iPhone
Log entries like the DHCPOFFER (as seen in your example) are generated individually by the corresponding process (for example, by udhcpc) using the Unix syslog mechanism (kind-of like the Windows Event Logging API)
By default on OpenWRT logging is handled by the syslogd process provided by the busybox package. This is fairly primitive and simply sends messages to the circular buffer you see using logread and/or to a UDP socket.
You can upgrade logging on OpenWRT to use the syslog-ng package. This has a much more advanced configuration and you should be able to use this to send filtered log events to a script that you can write to do what you need with them.
opkg install syslog-ng
syslog-ng is a GPL product but the documentation is now buried beneath a commercial web site, one would hope you can get it from the source code , via http://freecode.com/projects/syslog-ng. Note that OpenWRT seems to provide version 1.6.12 which I had trouble finding the documentation for when I implemented it on my OpenWRT devices, but eventually I found it via the wayback machine: https://web.archive.org/web/20070406054439/http://www.balabit.com/products/syslog_ng/reference-1.6/syslog-ng.html/x731.html (for example)
A configuration file fragment that would pull out those DHCP messages and send them to a standalone log file would look a bit like:
source src { unix-stream("/dev/log"); internal(); };
destination dhcp_messages { file("/var/log/dhcpmessages"); };
filter f_dhcp { match("dnsmasq-dhcp"); };
log {
source(src);
filter(f_dhcp);
destination(dhcp_messages);
};
You might probably find the pipe() or program() destination drivers the most useful for your application. For example, using a program() driver you could send selected messages to a shell script that parses them and saves them into a sqlite database.