Looking to enable/disable two networking adapters with Powerscript - windows

I'm looking to make a basic Powerscript to enable wifi and disable ethernet if the ethernet adapter is up and vice versa. Was thinking something like
If (Get-NetAdapter ethernet == Status Up)
Enable-NetAdapter wi-fi
Disable-NetAdapter ethernet
Else
Enable-NetAdapter ethernet
Disable-NetAdapter wi-fi
but I am having issues with writing the if statement to actually get the status of the network adapter. How do I properly write the If statement?

there are a lot of about topics that come with powershell.
for the IF statement you can check :
Get-Help about_if
for what you are trying to do:
if( (Get-NetAdapter -Name ethernet).Status -eq 'UP')
{
#some code
}
else
{
#some code
}

Related

Use powershell to find Which Adapter is being used

I have three Ethernet Adapters on my windows machine. All show status connected and up.
I want to understand how can I find from PowerShell which adapter is being used to connect to the internet. Via UI I can see Ethernet0 being the one but how to find that via powershell. Any ideas are welcomed. Especially something that is supported in powershell 2 as well.
PS C:\Users> Get-NetAdapter -physical
Name InterfaceDescription ifIndex Status
Ethernet0 Intel(R) 82574L Gigabit Network Conn... 15 Up
Ethernet1 Intel(R) 82574L Gigabit Network Co...#2 9 Up
Ethernet2 Intel(R) 82574L Gigabit Network Co...#3 4 Up
Get-NetAdapterStatistics will return information such as traffic on the adapter specified which you can use to create a script to listen for a change in value.
Here's some quick and dirty scripting using that cmdlet:
$keySet = #{}
:loop while ($true) {
$adapters = Get-NetAdapter -Physical | Get-NetAdapterStatistics
foreach ($adapter in $adapters)
{
if (-not $keySet.ContainsKey($adapter.Name)) {
$null = $keySet.Add($adapter.Name,$adapter.ReceivedBytes)
}
if ($adapter.ReceivedBytes -ne $keySet[$adapter.Name]) {
Write-Output -InputObject $adapter.Name
Break loop
}
}
}
By creating a hashtable, you can append the Name and ReceivedBytes property to it. Then reference the key values later on in your second iteration to compare from your first iteration. Using a while loop, you can set a constant listener to see which adapter will be the first to receive a packet; this in turn gives a different value of what's stored in $keySet and will break you out of the loop but not before outputting the Name of the adapter.
The issue comes with the adapters that are receiving any other traffic. That's something to be weary of. That is also something you can improve on later on down the road if you want to continue to use this example.
Hopefully this gets you on the right track.

How to write conditions from the long output in ansible - I have to implement conditions for healthchecks

I have a health check command( Health check for port)
root#mahesh$ show port ( This command will display the output like in the below)
Slot/Port Type State
1/1 ethernet Up
2/1 ethernet Up
4/1 ethernet Up
5/1 ethernet Up
management ethernet Up
in the above output State column needs to be always Up, If not I want to fail the task
How to implement such kind of condition.
I am aware of failed_when module but not getting idea , how to parse the output
What type of device is this? Have you looked to see if there was a module?
The status might also be in ansible_facts.
I would look there first.

Check auto-negotiated NIC speed on OpenBSD

How do I check the auto-negotiated speed of a network interface on OpenBSD?
When I force a specific speed, ifconfig will show it in the "media" line; but if the interface is in auto-negotiation mode, I can't find a way to retrieve the network speed effectively negotiated.
Thanks for your help!
If auto-negotiation is successful, you should also see it on the media line:
media: Ethernet autoselect (1000baseT full-duplex,master,rxpause,txpause)
The lack of the above output, or the need to force a particular speed, may indicate you have another problem (..bad cable; unsupported interface or hardware issue).

Iptables: Matching packets leaving a bridged interface

Apologies if you've already seen this over on serverfault, but it's been on there for several days now, and I've had absolutely no traction...
I'm building a firewall configuration tool based on iptables, and trying to get a "bump in the wire" scenario working.
Given a setup with eth0 and eth1 in a bridge br0 and a third interface eth2:
| | |
eth0 eth1 eth2
| == br0== | |
| |
| |
--- linux node ---
In this scenario, lets say I want TCP port 80 traffic to be dropped if it is going to the network attached to eth0, but allow it to eth1.
I am therefore trying to reliably match packets that go out over the specific interface eth0.
If I add the following iptables rule in the filter table:
-A FORWARD -o br0 --physdev-out eth0 -j LOG
Given a packet that originates from eth1 (the other half of the bridge), then the rule matches just fine, logging:
... IN=br0 OUT=br0 PHYSIN=eth2 PHYSOUT=eth1 ...
However if the packet origniates from eth2, then the rule no longer matches.
I appears that the routing algorithm can't determine which of the bridged interfaces to choose, so the packet is sent out over both interfaces in the bridge.
If I add another more promiscuous log rule, then I get the following log output for that packet:
... IN=eth2 OUT=br0 ...
My guess is that in the first case, the routing algorithm can just choose the other interface on the bridge since that packet shouldn't go out the way it came. In the second case, it hasn't chosen a specific interface and you then get no physdev information at all!
However, if the bridge has learned the destination MAC address (as shown by brctl showmacs br0) then it can determine the correct interface, and you get physdev informatino again.
(There is also a third case: where the bridge comprises three interfaces that this seems to apply to , then it still can't establish a single interface to send the packet on just be excluding the source interface.)
So, the question is, how can I reliably match packets the go out over eth0 regardless?
Given the example I gave at the start, it is not enough to just match packets that will be routed out over multiple interfaces, one of which is eth0 (though that would be useful in other scenarios). I want to be able to treat the traffic for eth0 and eth1 differently, allowing the traffic to eth1, but not eth0.
Reasons for observed behviour
The reason that iptables doesn't get the physical bridge information when the packet arrives from a non-bridged interface is that the packet has never been near the bridging mechanism, even though at this point we know we are sending it out on the bridge.
In the case where the packet did arrive over a bridge port, but it is an N>2 bridge, the problem is that the iptables PHYSDEV extention only provides for their being one value for "out", so it just doesn't bother telling us if there are two.
Solution
Use ebtables instead of iptables. The ebtables OUTPUT chain will know which physical bridged interface it is sending packets out on.
In the scenario above, where you want to filter packets that are leaving via a specific bridged interface (eth0), regardless of how it arrived into the system, add an ebtables rule along the following lines:
-A OUTPUT -o eth0 -j <target>
In a more complex scenario, where you want to filter packets arriving from a specific interface, and leaving via a bridged interface, it gets harder. Say we want to drop all traffic from eth2 (non-bridged) going to eth0 (bridged as part of br0) we need to add this rule to iptables:
-A FORWARD -i eth2 -o br0 -j MARK --set-mark 1234
This will mark any packet that comes from eth2 and is bound for the bridge. Then we add this rule to ebtables:
-A OUTPUT -o eth0 --mark 1234 -j DROP
Which will DROP any packet marked by iptables (as being from eth2) that is egressing via the specific bridge port eth0.
Acknowledgements
Thanks goes out to Pascal Hambourg over at the netfilter iptables mailing list for his help in coming up with this solution.

script to manipulate the dhcp/conf

i want to write a script to manipulate the dhcp.conf file. which in the sense, it has to read the file and it should ping all the lease IP and should give another text file, in which it should give the list of IPs, which devices are now existing.
EDIT: thanks for your swift reply. dhcpd.conf file is like this
lease 172.31.0.10 {
some text
some text1
}
lease 172.31.0.12 {
some text
some text1
}
lease 172.31.0.100 {
some text
some text1
}
so first i need to extract the ip address first and one by one we have to ping
Assumptions
First, there are two things you need to be aware of:
Not all devices respond to ping. Quite a few PC firewalls disable
ping replies. If you're on Ethernet, arping can be used instead and
will even detect firewalled PCs.
dhcpd leaves leases in the file which it /knows/ are no longer valid.
So, here is an example:
lease 192.168.66.132 {
starts 4 2009/01/08 23:58:41;
ends 5 2009/01/09 00:00:41;
binding state free;
hardware ethernet 00:e0:81:28:2d:56;
}
lease 192.168.66.133 {
starts 5 2009/01/09 03:17:17;
ends 2 2038/01/19 03:14:06;
binding state active;
next binding state free;
hardware ethernet 00:e0:81:28:2d:57;
}
You can see that 132 is not in use (binding state free) and 133 is
(binding state active). Another possibility is binding state backup,
but that only occurs in a failover config.
A lease can also be abandoned, which means that the DHCP server was
going to assign that IP, but found it was already in use (via ping).
This is all documented in dhcpd.leases(5).
Why are you wanting this?
The DHCP server already re-uses expired leases. Is there a good
reason that you need to check its work? If you're running out of
leases, have you considered lowering the lease time?
Does nmap -sP <start_ip>-<end_ip> do what you need? That'll also
detect machines with static IP addresses.
Re-writing the question
So, given the above, and assuming you still want this, I'm going to
answer this question instead:
Please write a script to find all leases which are either active or
abandoned and determine if there is currently a machine using that IP
address.
And so:
#!/usr/bin/perl
use File::Slurp qw(slurp);
use Data::Dump qw(pp);
use strict;
1 == #ARGV
or die "Usage: $0 dhpcd.leases\n";
my $leases = slurp($ARGV[0]);
$leases =~ s/^#.*\n//mg;
my #leases = split(/lease (\d.+\d.+\d.+\d+) {/, $leases);
shift #leases;
my %lease = #leases;
while (my ($ip, $rec) = each %lease) {
print $ip;
$rec =~ /^\s*abandoned;\s*$/m and print " abandoned";
$rec =~ /^\s*binding state free;\s*$/m and print " free";
$rec =~ /^\s*binding state active;\s*$/m and print " active";
print "\n";
}
This relatively ugly perl script will give you output like:
192.168.66.132 free
192.168.66.133 active
Which should be pretty easy for you to feed to arping.
the problem is, binding state active; does not means, the device is active. To make sure the device is active, we need to ping the devices first. there is no other way we can do it

Resources