I'm trying to establish a connection over SSH from my Win 8.1 laptop to my raspberry pi 3 model B as the host. Connecting over wifi works flawlessly each time, however I need to demo projects in class and the campus wifi does not play well with SSH, our professor stated that we must use an Ethernet connection. I have tried both putty and Bitvise SSH clients with same results - either "connection refused" or "no connection could be made because the machine actively refused it".
I have tried:
Enabling internet sharing on the Ethernet connection and enabling the SSH services (port 22 both TCP and UDP)
Disabling wifi on Win
Forgetting wifi on raspberry
Manually activating SSH server on raspberry even though I'm pretty sure it was activated already.
Deleting SSH keys from the wifi sessions
Completely disabling the firewall
ipconfig /release ipconfig /renew
Restarting both machines after every of the above
Reimaging memory card with newest Raspbian
Any help would be greatly appreciated.
Edit: The link What can be the reasons of connection refused errors? did not help, the listed reasons are closed ports or firewall and as I already said I tried to open the required ports through the shared Ethernet connection and turned off Windows firewall completely with no other firewall programs running. From my understanding Raspbian doesn't come with any enabled firewalls and allows all traffic. Can someone correct me if I'm wrong?
I finally found a guide that works: http://www.circuitbasics.com/how-to-connect-to-a-raspberry-pi-directly-with-an-ethernet-cable/
The crucial step was to set the static IP address of the pi to my laptop's Ethernet adapter address but modify the last part. You're welcome, all you poor souls from the future.
Related
This was woorking for me a week ago and I have no idea what changed.
I have a local http server on one device that I'm accessing with my Mac (through javascript),they are directly connected through Ethernet/a switch. I have the ethernet network on my mac set to a manual ip/mask to reflect the address of my server.
I can interact with my server perfectly when wifi is turned off on my mac, however, when I turn it on everything breaks and my requests to the server time out with no response (wifi is still functional).
Things I've tried:
Changing the network priority in network system preferences on my mac to make sure the wired Ethernet connection takes priority over WiFi. This changed nothing
Added a static route sudo route add -host [ip of http server] -interface en10. After I changed this, the server was unreachable even when wifi was down so I may have done something wrong
rebooted :)
I'm super lost here - any advice or any debugging tips would be much appreciated!
MacOS version: Mojave
I have a program listening on a local port(2080). I would like to forward all network requests to this program.
In order to accomplish this, I have configured the Wi-Fi network service to use a socks5 proxy as well as dns server pointing to local host.
This works as long as the Wi-Fi network service is connected to any network, regardless wether that network is connected to the internet. (For instance, a chromecast).
Is there a way to force the packages to the program without having to connect to a network?
Previous attempts include creating a network service attached to the lookback device, lo0, with the proxy and dns settings as before (couldn't get any packets to be routed through the program, network panel says not connected) And installing tun/tap discussed in this question.(Virtual network interface in Mac OS X).
The device will show up in ifconfig, but not in network services after editing the SystemConfiguration/preferences.plist
Any guidance is welcomed.
Nevermind I figured it out. The Tun/Tap will work, just need to configure the virtual network service with correct DNS and proxy settings.
I'd like to check the option to debug my kernel driver installed over remote physical machine (since I don't have firewire cables). Reading the relevant documentation, I haven't seen any limitation about remote physical debugging medium, so I deduced both firewire cables and ip over wireless network should work.
I thought that lldb remote connection using kdp-remote <machine-ip> would do the trick, but I don't get any response.
From remote VM however, it succeed even though the VM can be located on remote physical machine.
My boot-args configuration are keepsyms=1 debug=0x144 -v
We figured out the problem in the comments (item 2 below), but for posterity, here's a list of things to check if xnu kernel debugging isn't working:
The target machine must have a physical ethernet port which is connected via PCIe or Thunderbolt, or you must use a direct firewire connection (optionally via Thunderbolt). USB to ethernet adapters will not work on the target end. The client machine is less fussy, you can use wifi or USB-ethernet there.
The protocol uses UDP, not TCP. Have you got a firewall running on your lldb machine which might be blocking UDP packets? (You could try sending udp packets from target to client with the nc (netcat) tool while the machine is not crashed.)
Is the ARP entry correct on the client machine? arp <target ip> should yield the target interface's MAC address.
The crashed Mac will NOT respond to pings, only to KDP packets via UDP. So not getting pings back doesn't mean anything.
As far as I'm aware the machine won't request a new DHCP lease when it crashes, so that shouldn't be the problem, but you can always try setting a static IP address just to be sure.
Did you reboot after setting the boot-args? They only take effect on a fresh boot.
If SIP is active, you can only set nvram variables from the recovery environment from OS X/macOS 10.11 onwards. You can run nvram boot-args to verify that the settings stuck.
My personal recommendation is to use FireWire for kernel debugging if possible, it seems to be the fastest and most reliable in my experience.
With a blank init.lua, whenever I reboot the NodeMCU:
=wifi.sta.getip()
192.168.1.108 255.255.255.0 192.168.1.1
Where is it getting this 192.168.1.108? At one time a couple of weeks ago, I was testing the wifi module. When it connected it was with this ip.
How can that info be hanging around? Or is this some sort of internal ip that NodeMCU uses?
The answer is in the docs for wifi.sta.config:
Station configuration will be retained until changed even if device is turned off.
So, if you used wifi.sta.config("ssid", "password") in the past the device will try to connect to the WiFi "ssid" and obtain an IP (from the DHCP server) whenever it boots.
What firewall settings must be used on the remote machine for a remote kernel connection to work?
In particular I'm interested in connecting from Windows (front end) to a Linux machine (kernel).
I don't know the exact ports, but this is a generic way to solve most such firewall issues: (at least with connections using TCP)
Try to use the 'netstat -n' command and see which remote ports do the connections that are being blocked by the firewall use. They should be in the SYN_SENT state or something similar. Then on the remote machine open those ports and try to repeat this process until it works.