Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 9 years ago.
Improve this question
Motivation: I run wpa_supplicant without a network managing tool because I don't want to force new DHCP leases when my old ones work. This way I can get onto an old network very fast (as soon as wpa_supplicant establishes the lower network layers) if the DHCP lease has not expired.
Problem: But when the DHCP lease has expired, or if my IP address is from another network, I do need to call upon DHCP. I currently use dhclient, but dhcpcd is another option here. The problem is, even though these DHCP clients run in the background, they don't automatically realize that I need a new IP address, since I've got an old, invalid one.
Question: Is there a way to very quickly determine if I'm in need of DHCP? E.g. as a reaction to wpa_supplicant or as a response to contacting the standard gateway and realizing a connection isn't available. I can easily run sudo dhclient wlan0, and it gives me the address in one second. But what can I do to automate this process, when necessary?
Making unnecessary DHCP requests is not out of the question, but flooding the DHCP server is.
Elaborate question: For those of you who use wpa_supplicant directly, how do you DHCP?
Run dhcpcd again whenever you attach to a new network. If you have an existing lease it should be confirmed quickly.
If you object to typing in "dhclient" or "dhcpcd" everytime, you could automate it with a shell script. It could look something like
#!/bin/sh
dhcpcd wlan0 &
wpa_supplicant -d -c/etc/wpa_supplicant.conf -iwlan0
dhcpcd will say it is "waiting for carrier" until wpa_supplicant brings up the wireless link.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 2 years ago.
Improve this question
For example.
Lets say we have the following linux server:
host-server: 54.215.128.59
This servers will only accept connections from the following ip : 159.65.32.123
If a hacker only knows this information.
Could he be able to trick the host-server that the conection is coming from 159.65.32.123?
This way he would be jumping any firewall established.
It isn't very likely. Nothing is stopping you from defining you own IP address to whatever you want. In linux you can do it with (assuming you network interface is eth0):
sudo ifconfig eth0 159.65.32.123/24
If you are behind a NAT then you'll have to change its address and not yours. However, ISPs should have anti-spoofing measures in place that block packets with an IP address they didn't assign you.
There is also the problem of the return path. When the server will want to send something to this address, the packet will be routed according to the routing rules of all the nodes in the way, which are unlikely to point to the hacker's ISP.
If you are on a LAN with the server then it should be more possible, though you will likely need to handle the collision of IP addresses, and the problem of spoofing IP addresses on a different subnet. One option is to use ARP poisoning and do a MitM between the server and the router.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 6 years ago.
Improve this question
when I put this in the terminal
ifconfig eth0 69.69.69.69
the ip address in the terminal change but in the user interface not, I mean
initial state
my ip is 192.168.10.2
then a put in the terminal
ifconfig eth0 69.69.69.69
and this happens
terminal
properties
As we can see the properties didn't change.
what can I do for change that properties using the terminal or a bash?
You are probably using a Linux distribution that uses the NetworkManager daemon, and during installation it decided that eth0 should be configured via DHCP. So every time you manually setup its IP not using it (from a terminal in your case), NetworkManager will set it up again without noticing you within a few seconds or minutes.
To check if you have indeed NetworkManager running and managing eth0 setup, issue:
ps aux | grep -i networkmanager
If it is indeed running, look for more info about it, from Ubuntu for instance:
https://help.ubuntu.com/community/NetworkManager
...and then google around for "network manager manual setup ip".
PS:
I hate NetworkManager with a deep passion, gave up using it years ago and always uninstall it, managing my interfaces manually and/or the good old /etc/network/interfaces way. Noticeably (in my case) it can be a pure nuisance when multihoming and changing the interfaceS setup frequently. So if this is indeed your problem (90% sure) I can't help you much more with it. NetworkManager is good at managing one interface at a time, with one configuration (ex static or DHCP) for each interface. This satisfy 95% of user cases. But not mine.
i have try this in my computer and i have success
ifconfig eth0 192.168.218.110
if you want to chang the /etc/sysconfig/network-scripts/ifcfg-eth0 to chang the ip.
you can use vim edit chang thhis line:IPADDR=192.168.218.111
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 7 years ago.
Improve this question
I am trying to setup openvpn on a server so that I have 2 different tap interfaces (tap0 and tap1) and then a bridge connecting those interfaces. The idea is that a client on tap0 will be able to talk to a client on tap1 and vice-versa.
There is no physical NIC involved in the bridge and the Bridge interface is setup with no ip/netmask/broadcast.
I am able to ping between the 2 when they are both connected however I see no traffic when trying to tcpdump the bridge interface.
I am a bit confused on some things:
Do I need to have an ip configured on the bridge interface at all? I don't quite see the reason for it as all it will do is to make to virtual interfaces talk to each other
Is the fact that the bridge interface does not have an assigned ip/netmask/broadcast the reason I am not able to see the ping traffic on the bridge interface when tcpdumping that interface?
If the answer to number 2 is Yes, I assume that it is not either possible to use iptables to block/allow traffic on that interface, correct? If so is there any other way to accomplish what one would do with iptables on an interface like that?
I guess this wasn't the proper place to put this question but I thought I'd put an update anyway to close the issue.
Turns out that you do not need an assigned ip address on the bridge and it is possible to tcpdump. I happened to be working in containers which made the traffic go outside the vpn when pinging.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 4 years ago.
Improve this question
I have a linux box with a bank of modems and need to create demand-dial (outbound) PPP connections to a very large set of remote machines. Since I have far more remotes than local modems, I'd like to launch one or more instances of pppd in demand mode, but not allocate a particular modem until a connection is requested. When the connection becomes idle, I'd like pppd to release the modem so it can be used for a connection to a different remote.
I've been through the pppd man pages and understand the concepts of the call and connect options, as well as the options.DEVICE files and the /etc/ppp/peers directory. Lock files will tell me which modems are in use or available. And I'm able to connect to multiple remote peers as long as I hard-code the modem assignments. But I haven't found a way to assign them dynamically, say by calling a get_available_modem script when pppd needs to dial. Google doesn't seem to know, either.
A work-around might be to detect the need to demand-dial with an external mechanism, and then launch pppd to service it, but it seems cleaner to leverage the facility within pppd itself.
Any pointers or ideas are appreciated. Thanks for your thoughts!
This is the solution I'm going with:
Enumerate the modems as /dev/modem0, /dev/modem1, ...
Start an instance of pppd in demand-dial mode for each peer, but instead of a "real" modem, attach it to /dev/modem.peer, which the "ppp-on-dialer" script soft-links to the first available modem dynamically.
When the connection times out and the modem goes offline, soft link /dev/modem.peer to /dev/null so the modem can be re-used for a connection to a different peer.
Thanks for your comments!
Does it have to be directly driven by the Linux box, or could you use something like the old Lucent Portmaster boxen?
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
I work with embedded Linux systems that sometimes want to get their IP address from a DHCP server. The DHCP Client client we use (dhcpcd) has limited retry logic. If our device starts up without any DHCP server available and times out, dhcpcd will exit and the device will never get an IP address until it's rebooted with a DHCP server visible/connected. I can't be the only one that has this problem. The problem doesn't even seem to be specific to embedded systems (though it's worse there). How do you handle this? Is there a more robust client available?
The reference dhclient from the ISC should run forever in the default configuration, and it should acquire a lease later if it doesn't get one at startup.
I am using the out of the box dhcp client on FreeBSD, which is derived from OpenBSD's and based on the ISC's dhclient, and this is the out of the box behavior.
See http://www.isc.org/index.pl?/sw/dhcp/
You have several options:
While you don't have an IP address, restart dhcpcd to get more retries.
Have a backup static IP address. This was quite successful in the embedded devices I've made.
Use auto-IP as a backup. Windows does this.
Add to rc.local a check to see if an IP has been obtained. If no setup an 'at' job in the near future to attempt again. Continue scheduling 'at' jobs until an IP is obtained.