So I had been working on a project that is able to setup an Access Point and redirect traffic through another interface (can be wired or wireless).
Now there have always been issues between hostapd and wpa_supplicant, I needed to create an access point on one wireless interface and route it through another wireless interface. But while that interface is managed by network-manager hostapd is unable to start an access point on that interface.
Ways to work around:
I can run these commands and kill wpa_supplicant
sudo nmcli nm wifi off
sudo rfkill unblock wlan
But this turns off all wireless interfaces and I need one connected to the internet so I can route the traffic.
Another work around, which I used and is a lot more elegant:
adding this line to the NetworkManager.conf file
[keyfile]
#unmanaged-devices=mac:d8:5d:4c:9a:72:60
This actually worked flawlessly!
Until a recent update of hostapd to version 1:2.5-2+v2.4-3
Are there any other workarounds so that my wireless interface is not managed by wpa_supplicant?
I'm running Kali Linux.
Okay so for anyone having the same issue, you can also add
[keyfile]
unmanaged-devices=mac:d8:5d:4c:9a:72:60, ,interface-name:wlan1
that 'interface-name' option solves the problem!
Related
In systemd, MDNS (avahi-daemon) stops broadcasting the network interface after the network restart. However, for the same scenario, in system init, MDNS will work perfectly normal.
Tried:
Changed the avahi-daemon configuration file
restart the avahi-daemon after restarting the network
Checked the firewall (no firewall)
Tried systemd-resolved
Changed hostapd configuration
I am so glad that I have it figured out. The reason why the MDNS stopped broadcasting is because the interface didn't properly restart.
In systemd, after the network restarts, it requires a reload of the configuration manually to generate an IP address. So after restarting the network, manually reloading the network interface configuration by ifconfig interface down and ifconfig interface up (interface need to be replaced by the real interface name).
Also, purely doing a ifconfig interface up won't work. The network interface probably has a cache. So bring the interface down ifconfig down can help remove the cache.
Please correct me if any of the description above is wrong. Thanks.
I am not able to connect to vulnserver using netcat.
I type this to connect
nc -nv 192.168.70.130 9999
(UNKNOWN) [192.168.70.130] 9999 (?) open
and it says this forever and doesn't happen anything
I have disabled real time protection, allowed in firewall and also VM is set to NAT mode.
Is there any other way to connect or what might be the possible issue.
I have also encountered the same issue. I thought it was my VM acting up, so I restarted the network access. I tried allowing vulnserver.exe through my windows firewall. Neither of them solved the issue. Finally, I disabled windows defender firewall and now it works like a charm. But before doing this, try to ping the windows machine from the linux box. If there's a response it should work. If there is no response however, try enabling file and printer sharing in windows. For more info, read this...https://superuser.com/questions/1137912/ping-to-windows-10-not-working-if-file-and-printer-sharing-is-turned-off
Immunity Debugger and vulnserver has to run as administrator, then Immunity Debugger can see vulnserver, otherwise Im..Deb can't see because of less privileged then vulnserver.
Also we need run Immunity Debugger
That's mean port 9999 has already been opened which is expected if you're already executed vulnserver
wolf#linux:~$ nc -nv 127.0.0.1 9999
(UNKNOWN) [127.0.0.1] 9999 (?) open
Welcome to Vulnerable Server! Enter HELP for help.
It also means that you've already connected to the server. Go ahead and type HELP to see more info.
Try to setup using different network mode such as internal or host-only mode.
I just had a similar issue - I'm not sure if you are using it in conjunction with Immunity Debugger like me (as part of an ethical hacking course) but I kept getting that situation because I forgot to hit 'play' on the debugger.
I'm really looking for advice and a starting point more than anything. So I'll try my best to explain my end goals and the challenge. I want to set up a local WiFi connection (P2P) between a Rpi3 (or any embedded system really, running linux) and a laptop. The Pi should be the server and laptop the client. The raspberry PI is going to be reading samples over USB from an SDR. I want the laptop to be able to connect to the network the pi throws up, and be able open a browser and view the results. I'm guessing what i need to read up on is ports/sockets and web programming in general. The cheepy IoT sensors and light bulbs seem to be able to do this (opening network and forwarding data) relatively easily but i cannot find any information online to aid in my quest. All the Best and thanks in advance.
Since the embedded system will be running Linux, you can do something along the following lines:
setup the wifi as an Access Point (example). Also setup DHCP Server (example), so the wifi will assign an IP address to connecting laptop.
Install a webserver (e.g. Apache).
Create the webpage/ web application you need to "serve" the data. Install this into Apache.
Ask follow-up questions if you like.
I tried to set static ip from command shell but after reboot raspberry lost configuration.
I also tried to configure the WiFi peap in the wpa_supplicant.conf file but I did not get any results.
Do you have any suggestions on how to solve these problems?
I hardly found documentation about this, but it seems like Android Things will only work if its address is given by a DHCP.
Even if you set it manually with the ifconfig command, it will return an error and the IP you just set will not be usable...
Very new to the Self Host WebApi, but I am very impressed with its ease of use and extendability. At least through this tutorial. Everything I've done so far works on my development machine whether I use localhost, 127.0.0.1, or my LAN Ip (192.168.0.x) but I am baffled why I can't access the service from any other computer even others in the same subnet.
In short after going through the tutorial on the machine where it is running:
Browsing to
localhost:3636/api/products/
results in the expected xml return.
On another machine on the LAN browsing to:
192.168.0.x:3636/api/products/
results in a timeout
Data points for those who might know how this all interacts:
1.) My dev machine(192.168.0.x, server, host whatever you want to call it) has IIS on it; I was so paranoid it was in the way that I stopped it via the Administration GUI
2.) I have reserved the URL/Port with the following command line executions:
>netsh http add urlacl url=http://+:3636/ user=DOMAIN\USER listen=yes delegate=yes
>netsh http add urlacl url=http://192.168.0.x:3636/ user=DOMAIN\USER listen=yes delegate=yes
2.b) I've tried both of those together and individually, and tried changing the user to "everyone" to no avail
3.) I have tried to change the code in the tutorial to set the
config.HostNameComparisonMode = HostNameComparisonMode.Exact //default is Strong Wildcard
4.) I can successfully ping and tracert to 192.168.0.x from other machines on the LAN
5.) A friend recommended I setup a TCPListener and ensure I could telnet to that to eliminate the firewall as a possibility. If that logic is sound, the firewall isn't the problem
EDIT: Thanks for your help, here's another data point that I believe confirms it's not a firewall issue. I previously posted this connection when behind a rather obtuse (at least to a non Certified guy like me) Juniper Firewall/Router. I have since redone the tutorial on another machine (without IIS) on my home network and still cannot publish the service to other computers within my LAN. Any ideas?
Well it wasn't the hardware firewall, it was the windows firewall! yikes i wasted a bunch of time on that. Once I turned off the windows firewall (the code runs in an intranet anyway) everything worked.
Anyone know of a good site that explains how firewalls and wireshark interact; or i suppose that just has to be one's first test.
I would try a couple things:
First off, get rid of the HostNameComparisonMode line. That might actually disable requests coming from other machines.
If things still don't work, try getting rid of the URL ACLs and run your application as an administrator and see if that works. If that works, you may be able to add the URL ACL back on and not have to run as an administrator. You should only need the one with '+' as the hostname.
I faced the same problem when i tried to self host using OWIN. What worked for me was -
Run Visual Studio as an Admin
Remove any and all netsh urlacl port registrations that I had added while debugging this issue
Add a inbound rule to my windows firewall
I followed the instructions on this link
https://learn.microsoft.com/en-us/dotnet/framework/wcf/samples/firewall-instructions
Check out the section - To enable a port range in advance
That's it! I was able to call my api from other computers on the network.
Hope this helps...