I am trying to follow directions from the book Exploring Beaglebone. I have also viewed this video which is wrong OSes. I have also read some posts (one, two).
Observed anomalies:
Network Preferences shows a warning of a self-assigned IP address and inability to support internet sharing:
macOS Network Preferences
Debian does not have a 'udhcpc' command but the following was executed:
Screen output
Has anyone been able to do internet over USB on macOS 10.13.2 and Debian 9 IoT?
tnx,
Jon
So a quick intro to what options you have:
Manually enable routing + NAT (No idea how to do that on OSX)
Configure the board system to use DHCP client functionality instead to talk to a shared connection from e.g. OSX.
Permanently disable the script (should be in /opt somewhere) that assigns the current network settings and enables DHCP serving. Might also just be a part of a larger script.
Enable DHCP client (e.g. in /etc/network/interfaces or by using Connman or Network-manager)
The default Debian image should also expose a serial console over USB. You can use this to gain access to and configure the system even when your network connection doesn't work. Of course, the debug-UART should work as well, by using a USB-serial converter.
Another note: the DHCP client on Debian for manual execution is usually dhclient. The interface on the Beaglebone side will be named usb0 or usb1 (as newer images use two types for increased compatibility e.g. with OSX).
A good place to ask questions is usually the Beagleboard Google group
Related
I am trying to build a project using rpi pico and W5500 shield module with micro python.
I am struggling to find the proper libraries for that but I am unsuccessful so far. The documentation of micro python references in https://docs.micropython.org/en/latest/library/network.LAN.html?highlight=lan%20module:
class LAN – control an Ethernet module¶
This class allows you to control the Ethernet interface. The PHY hardware type is board-specific.
Example usage:
import network
nic = network.LAN(0)
print(nic.ifconfig())
# now use socket as usual
...
but I am not sure which network library to look for or how to install it in thonny and so the importing is unsuccessful. When in Thonny tools/manage packages/ and I search on PyPl for "network" there are many libraries coming up but which is the proper one?
Can somebody point out the proper library?
You'll need a MicroPython firmware build that includes support for the Wiznet modules with RP2040 / Pico. There's a guide on the Wiznet GitHub (it also goes on to talk about how to compile it yourself, if you need to go that far). It does look like the support for the W5500 on rp2040 has only just hit the nightly builds of MicroPython (I usually run with the current nightly versions myself, so you could give the latest build direct from micropython.org a try)
Once you have a firmware that includes the right support, the following code should work:
import network
nic = network.WIZNET5K()
nic.active(True)
# to print IP address etc
nic.ifconfig()
Also, the current link to the MicroPython docs on these network adapters is this one, rather than the link you shared to the generic network / LAN class.
Host machine: Debian 10 running NoMachine 7.2.3
Settings:
Specified H264
User Hardware Encoding enabled
Use Specific Frame Rate enabled (60FPS)
Use Acceleration enabled
Client: Windows 10 running NoMachine 7.2.3
Both machines have monitors attached.
Using NX protocol for connection.
FullScreen / Scale to Window / Desktop is currently 2560x1440 (reduced from native while testing this issue)
Specific issue:
I do a ton of work in the terminal and when viewing desktop via nomachine, the terminal caret is randomly not visible. The same issue is less noticeable with right click menus and other areas of "visual updates in small screen space." If this were another remote desktop vendor I would try to find the "don't update just regions" setting to force the entire display to update regularly, but I can't find similar settings for nomachine. I have a dedicated gigabit connection between the two machines with no other traffic on that line, so bandwidth is not an issue.
To recreate:
I disabled caret blink (using universal access / accessibility settings) so the caret is a solid block in terminal / vi. If I edit a text file in vi and move up and down, the caret will only update visually every other line or so (verified on the physical screen it is moving correctly). Same if I highlight or insert, etc. You inevitably miss a character or so or lose your place).
I have tried changing speed vs quality slider, resolutions, swapping from h264 to VP8, etc.
I have disabled:
multi-pass display encoding
frame buffering on decoding
client side image post-processing
Nothing seems to change this specific issue. Yes I can make dragging a quarter-screen-sized terminal window smoother, but that doesn't help me follow the caret in vi/vim. Both machines are nicely spec'd (client has 16G / RTX2080, server has 32G / GTX1080)
Is there a way to get nomachine to update all the screen all the time, or at least better refresh small areas like a terminal caret?
(OP): Based on a night of troubleshooting, the issue seemed to be either:
An issue with the Debian install of the nvidia drivers
The server machine is a laptop with a broken main screen (but with an HDMI external monitor plugged in). The Debian X-server may have been confused as to whether it was headless or not and caused issues with nomachine (which tries to detect headless and start a virtual session).
The solution to this exact problem would be to disable the GUI and force a virtual session, per https://www.nomachine.com/AR03P00973 (dummy dongles won't work because the laptop's main display is not a standard plug).
In my specific case, I needed GUI access on the server at times so I couldn't use the above methods, and I could not remedy the problem with Debian, so I wiped the system and installed Ubuntu 20.04, which is more forgiving with graphics drivers and monitors. After setting up the Ubuntu system as similarly as possible to the Debian system and letting the proprietary nvidia drivers auto install, nomachine connected at the same resolution and worked perfectly, without the lag in small screen areas.
I have a computer with Windows 10 and a Virtual Machine (VBox) with a Windows 10 system that I use for work, I never had a problem since today : I launched it and didn't have any access to internet.
I didn't change anything since yesterday so I don't really understand what is happening.
I tried restarting the machine a few time but nothing changed, here's my configuration :
EDIT : I tried with differents interface type nothing worked
It may depends on your network device configuration.
First of all you should set you first interface to NAT and enable the second one to HOST ONLY ADAPTER
At least this config is what works for me, if it doesn't work, it may depends on your interface network devices config, but i don't know how that works on windows.
I was actually using a software mhotspot on my windows 10,so that i can create hotspot from my laptop,and it was working nicely. But few days back,my windows got updated and from then whenever I try to create the hotspot ,it shows me "Driver problem found !" . It may be for another reson but I suspect that it went wrong after the updation of Windows. I have tried almost every action to retrieve the hotspot,but no use. surely I am missing something crucial delicated fact. Anyone would help me please? I know this topic is bit odd. But I needed help badly and I believe I can get best help from this site.
You can create a hotspot very easily using cmd.
Give it a try.
Source: Create a hotspot in windows 10 using cmd
I solved my own problem. Actually in the updated windows 10 , microsoft hosted network virtual adapter is missing. But we can install windows 8 hosted network virtual adapter here. we need to goto device manager. And there from network adapter we need to uninstall the wireless LAN adapter . And after that installing windows 8's wireless LAN adapter would lead to the final solution.
Here is the link for windows 8's wireless LAN adapter.
http://global-download.acer.com/GDFiles/Driver/Wireless%20LAN/Wireless%20LAN_Atheros_11.0.0.492_W81x64_A.zip?acerid=635651781611978929&Step1=NOTEBOOK&Step2=ASPIRE&Step3=ASPIRE%20E5-573G&OS=81P1&LC=en&BC=ACER&SC=PA_6
And now we can easily create hotspot again from windows.
Context:
I am writing a program, which uses pcap to capture packets in the monitor mode on the openwrt router with ar9331 chip.
I tested the program on a desktop with pcap 1.1 (which existed in my openwrt version) and found an issue: pcap_can_set_rfmon returned true, pcap_set_rfmon returned success, but attempt to activate capture resulted in “monitor mode isn't supported” error.
Google search showed a bug report of similar issue with wireshark. One of the comments says that with some wi-fi devices the issue is caused by an old version of pcap, which uses old version of another lib.
I updated pcap version to 1.5.3 and the issue was resolved.
Problem:
The issue appears again when I port our program to Openwrt. But now update of libpcap package to version 1.5.3 from newer openwrt branch doesn't help.
Sadly, the libpcap monitor-mode code on Linux works best when libpcap is linked with libnl, and it's often not linked with libnl for various reasons (including problems with a program using libpcap and libnl, and linked with a different version of libnl than the one with which libpcap is linked).
This needs to be redone in libpcap. It may end up being done with a "helper process" that libpcap runs to do various things; that would also improve cleanup if the program using libpcap exits abnormally and would allow packet capture operations requiring special privileges to be confined to the helper process rather than requiring the program using libpcap to run with those privileges. This is on my rather long to-do list.
The best workaround is probably to use airmon-ng to turn monitor mode on, as described in the Wireshark Wiki page on Wi-Fi capturing.