I have connected a PiCAN2 board with raspberry pi running latest Jessie. When I try to send some CAN messages to my PC ( PC is connected via a USB to DB9 CAN interface to the PiCAN2 board) through this PiCAN2 using the can-utils, it runs into ERROR-PASSIVE state as soon as I bring the CAN interface up. But, when I enable loopback mode, I am able to send messages and receive them using two different terminal window on the raspberry pi itself. I enabled loopback mode using
sudo /sbin/ip link set can0 type can bitrate 500000 loopback on.
Can some one tell me more about the loopback mode? I want to make sure that my hardware setup for PiCAN2 is correct. Is it possible to confirm that my CAN board is configured correctly because I can send/receive messages using loopback mode?Or this doesn't necessarily mean that it is correct?
I also want to know why I get the ERROR PASSIVE mode - does it indicate that the PiCAN2 is not configured correctly OR does it mean that my USB to DB9 CAN interface has some problem? I am new to this area and any help would be nice. Thank you.
Related
I possess the USRP X310 with a Basic TX daughterboard installed. My plan is to use it via 10GbE together with LabView with a Win10 host machine.
I have connected the SDR with an Ethernet cable using Port 0 and the included SFP adapter to my host PC's (1GbE) ethernet interface for network testing purposes. The ethernet adapter is configured to use the static IP 192.168.10.1. Furthermore I have installed the UHD (uhd_3.15.0.0-release_Winx64_VS2017.exe). However when the device is connected and powered on, I can neither ping 198.168.10.2 nor detect it running the uhd_find_devices.exe. I have also started the NI-USRP Configuration Utility which I recently updated but it was not able to detect the SDR either. I do observe that none of the LEDs on the back is illuminated (especially not the Port 0 ethernet).
How can I get it working?
If you've worked with other usrps (I have a few), then you'll find the X310 to be somewhat different, to the lower models.
Anyway, there are different fpga loads / images, which corrospond to whether you are trying to connect via a 1G or 10G module.
"The PCIe interface is always available regardless of what FPGA image is loaded. Ettus ships two FPGA image variants, the HG or HGS image which has one 1 GigE interfaces and one 10 GigE interfaces, and the XG image which has two 10 GigE interfaces.
So you need to be sure you have the right image to connect to it via 1GE... or I expect it won't work, as it seems to be.
HTH's.
I have Raspberry Pi 3 model B
OS: Raspbian(jessie)
I want to create a connection from my smartphone to a headless raspberry, and connect the headless raspberry to a network(which the smartphone is conencted).
like the vacum cleaner robot (IRobot) or Web camera which has an app, or any device that needs an initial connection to setup it's network.
the initial connection needs to be from a remote device, mainly a smartphone app.
What did i try:
1. bluetooth - i've managed to setup the bluetooth in the raspberry. when i try to connect, a popup appears on the raspberry which ask to confirm connection, because the raspberrry needs to be headless, this option is not good for us.
if i set the bluetooth as follow: sudo hciconfig hci0 sspmode 0
when i try to connect to the raspberry, a popup appears in the smartphone required a PIN code, this option may be good, if i new the PIN code.
2. P2P - i try use wifi direct from my smartphone
i've create file called p2p.conf inside /etc/wap_supplicant
inside this file i wrote the following:
ctrl_interface/var/run/wpa_supplicant
update_config=1
device_name=raspberry
device_type=1-0050F204-1
driver_param=use_p2p_group_interface=1
p2p_go_intent=1
p2p_go_ht40=1
then stop the wpa_supplicant and change
sudo wpa_supplicant -B -iwlan0 -Dnl80211 -c/etc/p2p.conf
i've started wpa_cli
and then p2p_find
it's started scanning
when i search from the smartphone for the raspberry, i found the raspberry, when i try to conenct it asks me for PIN code, the PIN code is showen in the raspberry wpa_cli.
two problem i have from this option:
1. the network needs to be connected.
2. the PIN code changes, and i can't make it fixed.
Is there a way to make an initial connection to setup a network from the smartphone to a headless raspberry?
First allow me to say that I don't have any experience developing drivers for OSX, nor drivers for Windows. So, there are a lot of things that I don't understand about how drivers work; I'm sure it'll be evident in my question.
I have a modem that is able to open and close TCP/UDP sockets using AT commands. I would like to create some kind of program (kernel extension? driver?) that implements a network driver, converting the network interface calls into AT command serial messages.
That's the basic jist of it. I'm essentially asking if anybody can point me in the right direction / give me a high level overview of how they would approach it and what Apple guides to focus on.
The XNU networking stack -- like most network stacks -- expects network devices to send and receive IP packets directly. It isn't tooled to work with network devices that handle part of the network stack (like TCP or UDP) internally -- it won't be possible to implement a network driver which uses this device.
You might have more luck exposing this device as a SOCKS proxy. You will need to write a userspace daemon which listens on a TCP port on localhost (on the computer) and relays traffic to the serial device; once that's done, you can set the computer to use that device as a SOCKS proxy in the Networking control panel.
(As an aside: most devices that implement this type of interface have a very low limit on the number of open sockets -- often fewer than 10. They're unlikely to be able to handle the network load generated by a desktop OS.)
I am trying to modify a ethernet driver using WDK tools provided in Visual Studio 2012.
The samples provided in the WDK are 'miniport adapter' and 'NDIS Light Weight Filter' among others. I am still at the very beginning of driver writing and hence finding it tough to navigate through the code.
I was able to install the miniport adapter after building it in Visual Studio 2012 [Shows up as 'Microsoft Virtual Miniport Adapter' in my network adapters list.] I am able to assign it a IP address and Subnet mask also.[I found out that this does not connect to any physical device on my PC].
I also setup the 'Debug View' software to check the driver messages from my adapter.[ I used 'DbgPrint' statements in the code and then built it.] But, The debug messages are printed repeatedly.
1- Why are the messages printed again and again? The messages are from the 'datapath.c' file of the program and is from the function 'MPSendNetBufferLists'. ['Net Buffer' specifies data sent or received on the network.]
2- I setup Wireshark to capture the data on the adapter and it shows that there are requests from ARP,HTTP,SSDP,MDNS etc coming out of it. I am not able to understand what is actually talking to the adapter? and how can I stop it from talking?
I can use 'ping' to see if there is a connection on the IP address I have assigned to the adapter and it responds with a success telling all packets were sent and there was no packet loss.
My goal is to send and receive 'data' packets via a IP address to this ethernet adapter. ie- I want an application to connect to the IP address assigned to the adapter and talk to it.
3- Can I actually do it with the samples provided in WDK?
Any other suggestions or advice are welcome.
PS- I wasn't able to use the windows debugger built into Visual Studio 2012. I used 2 PCs and was able to connect and install the driver onto the 'target' PC but couldn't do anything with breakpoints etc. The code and Program just did nothing after installing the driver on the 'target' PC. Any suggestions on this?. I thought I could do step-by-step debugging of drivers also.[I know I am wrong].
Thanks
Aditya
NDIS miniport drivers, like many low-level drivers, are meant to talk to hardware. The miniport's responsibility is to take send packets from the OS, translate them into whatever format is required by the hardware, and instruct the hardware to send the packet on the wire.
The WDK could (and in fact, used to) include a real-world sample driver that sends packets on real-world hardware. But this leads to some confusion, since real-world drivers have to deal with lots of hardware-specific details that distract from the main point of the sample. If you starting from a real-world driver, the first thing you'd have to do would be to identify all the hardware-specific bits and rip those out, so you could replace them with your own hardware-specific bits.
Instead, the "netvmini" sample in the WDK is a fake driver. That means it pretends to have actual hardware, but secretly it's all a lie. When the OS sends packets to netvmini, the netvmini driver will simply broadcast those packets to any other netvmini miniport adapters installed on that machine. (In effect, installing 2 netvmini adapters on the same machine simulates what would happen if you had two real adapters plugged into the same Ethernet hub.) So in ASCII-art, this is what happens if you install two netvmini adapters on the same system:
TCPIP TCPIP TCPIP
| | |
Real physical miniport Your netvmini #1 Your netvmini #2
| \ /
[The Internet] [The netvmini virtual hub]
As hopefully the ASCII-art illustrates, your netvmini adapters don't have any path to the Internet. So your driver won't get a "real" IP address that can route to the Internet until you add in details of your hardware. Until then, Windows will just keep trying to send ARPs and HTTP requests that will never go anywhere.
To answer your specific questions:
The messages from MPSendNetBufferLists are printed every time the OS attempts to send a packet. Because the OS thinks that you have a real network connection, the OS will make several attempts to use it. Eventually that should quiet down a bit, when everything comes to the conclusion that this isn't a useful link.
The requests are coming from TCPIP. If you don't want TCPIP to send data, then unbind it from the adapter.
You can definitely send data to the adapter. In fact, you've observed that you're already sending random HTTP packets and etc. But the data won't actually reach the Internet, until you teach the driver how to talk to your real hardware.
If you're sitting there thinking "but I don't have hardware!", then you might want to create a virtual miniport of some sort. Virtual miniports are like netvmini in that they don't have real hardware, but they still do have some way to get the packets off the machine. For example, VPN miniports that operate at layer-2 (like L2TP) will typically install a second driver — an NDIS protocol driver — that sends and receives data from the "real" physical miniport. Then the virtual miniport talks to its protocol whenever it needs to get packets off the machine. The result is:
TCPIP
|
Your virtual miniport
|
Your NDIS protocol
|
The real physical miniport
|
The Internet
There are alternative architectures; for example, a VPN that operates at layer-4 (like SSTP) might decide to open a WSK socket instead of implementing an NDIS protocol driver:
TCPIP
|
Your virtual miniport
|
WSK socket
|
TCPIP
|
The real physical miniport
|
The Internet
I am running a USB cell modem via PPP in Embedded Linux. I can use AT commands via minicom to connect to the modem and interrogate the signal strength (AT+CSQ) when the PPP connection is not active. However, when it's active, this is not possible.
Is there any way to retrieve the signal strength from a PPP connected USB cell modem while the PPP connection is being used? I am open to an API or any other method available.
I don't have a umw190, but the Linux driver for the modem should have more than one ttyACM character device available. Use one for PPP and the other for AT+CSQ. Check dmesg for cdc_acm to see.
If your embedded device has udev then both devices should automagically appear in /dev. If not you'll have to mknod more. Off the top of my head major number is 166 for cdc_acm.
What does the physical setup look like?
1. Are you using a modem that is on a board designed/printed by the same company as your SBC?
2. Is it connected via something like PC104 serial or USB?
3. What specific modem are you using?