I am confuse among various interfaces of ethernet .I am just going through this U-Boot Link
http://www.denx.de/wiki/DULG/UBootEnvVariables
Where it says
ethaddr: Ethernet MAC address for first/only ethernet interface (= eth0 in Linux).
Now my confusion is eth0 is only real interface whose address is programmed into efuse register
Is other interfaces like eth1 ,eth2 and so on virtula interface which will be configured by applcation later on .
Also from this link
http://e2e.ti.com/support/arm/sitara_arm/f/791/t/209421.aspx
Where it says
The MAC addresses programmed into the internal e-fuses will be from the TI address pool. Customer will need to add some type of storage device (Flash, EEPROM) which contains their MAC addresses if they want to use addresses from their own address pool.
Now are these two mac address one written in e-fuse and other in Flash by customer two different address for eth0?
This uboot documentation is for many different kinds of hardware, some of which have only 1 interface, and some of which have more. The language "Ethernet MAC address for first/only ethernet interface (= eth0 in Linux)" just means that referenced variable is for eth0, which is the first ethernet interface. If there is only one interface, it is still called eth0. If your hardware has multiple ethernet interfaces, the other variables are for them.
Regarding the second question: it appears that this hardware device has a built-in ethernet controller, which needs a unique MAC address to function on a network. The device ships with a MAC address already configured (written into the e-fuse of the device, and therefore read-only). If you don't want to use that MAC address, you can instead use flash or EEPROM to store your own MAC address to configure the ethernet controller. Only one of those choices will be active.
One reason you might want to change the MAC address is that MAC addresses are assign in blocks to different vendors, and the shipped address is from the TI block. That means network analyzers will think the overall product is a TI device. If you want your product to appear as a different vendor, you need to use your own MAC address drawn from your own pool. If you don't know what this means, don't worry about it: use the one that is preconfigured and built-in.
Related
The closest thing to a solution I've found is using Get-NetConnectionProfile to return all active interfaces, which works fine when there's only an active physical interface and the VPN itself. However, this would not work if the user's machine has 2 active physical interfaces (e.g Wi-Fi + Ethernet) along with the VPN.
Ideally, I'd like a solution that works similarly to "ifconfig -v" in MacOS, which tells you the effective interface for a virtual interface:
Unfortunately it seems there is no sure-fire way to get the underlying physical adapter for a VPN using a Windows API. Short of involving a packet sniffer such as Wireshark, the best solution I found involves parsing the output of two PowerShell commands: Get-NetAdapter and Get-NetRoute.
With the information from these commands, I can know which interfaces are virtual and which ones are physical, and I can rank the physical interfaces by 3 different criteria (in case of tie, we move on to the next criteria):
Sorting the physical interfaces by the interface metric + the route metric to the default gateway (0.0.0.0).
Wired connections over wireless ones (PhysicalMediaType=802.3).
Prioritizing faster adapters.
With this logic all the VPNs I tested appear to reflect the expected network interface, although some VPNs let you force traffic through a particular physical adapter in which case obviously this all goes out the window.
First,
You can install wireshark or some other traffic monitoring tool and capture the relevant packets (filtering using openvVPN protocol or port etc.)
Second,
As far as I know there is no hard linking between the virtual network interface and the regular (ethernet, WIFI etc.) interface, at least not in OpenVPN (there are diffrent VPN protocols). The openVPN packets will be routed to the remote server using you OS routing table.
This way if your ethernet interface is your primary default gateway, and it gets unplugged, your VPN service will be able to recover, since it will have a route to your remote VPN-server address using your WIFI interface.
To my understanding, the mac address is supposed to be hard wired on the network card. It is also the so called physical address, and it should be unique. But it is allowed to be modified by the OS, say Window 10. So, is it really communicate with other machine by the new MAC address? Or is the old MAC address still existing on a mapping table somewhere? Is there any rule for creating the custom MAC address? Also, if it is changeable, then it is not unique anymore. What is the point for a hard wired MAC address if it is changeable?
Thanks
What is a Mac Address?
The real Mac address of the network card is unique and immutable.
the Mac address is used on the local network to route the packets :
the router/pc will say : "who has 192.168.1.4?"
The pc with this ip will answer "192.168.1.4 has DC:23:F5:B5:FF:31:94"
The PC/Router will send the packet via ARP protocol to the specified Mac address.
Why virtual MAC Address?
The Mac address allow everyone on the network to identify informations like the brand of your network card, and to follow you're connections on the network through the time. Some router will use the ip address to attribute a same ip address to the same device at each connection.
Fact is, on a public network, you prefer to have a fake Mac address in order to be annonymous. Reducing the risk of attack targeting a specific network card brand.
Problems related to MAC Address
if 2 devices (E.g. VMs) have the same Mac address but different IPs, half of the packets will be received by each network card. And on the computer you will see unexpected disconnection/reconnection really often.
another related problem would be an attack by ARP poisoning, which is an attackant saying " < has <mac_attackant>" resulting in packets sent to an attackant instead of the router (man in the middle)
Rules for creating a virtual MAC address
the macchanger tool on Linux allow you to change your Mac address and can be configured to take a complete random Mac address, a random Mac address belonging to a valid manufacturer, or to have a Mac address from the same manufacturer as the real Mac address, or a specific Mac address you can specify. So, except the size of the Mac address there are no specific rules.
(* The MAC and ip i chose are totally random.)
I am recently read documentation about Windows-Driver-Model, one of a chapter of it says :
Before a driver is installed for a new device, the bus or hub driver to which the device is connected assigns a hardware identifier (ID) to the device.
But how ??
For example the OS want to communicate with a USB device.
How can it ( the os ) obtain the hardware-id of the device ?
Is there some kind of protocol to communicate with the hardware that works like :
The OS send a signal ( or USB formatted message ) with a body of such as "I want to know hardware-id"
The hardware must response to this message to OS with a body of such as "My hardware-id is xxx"
If there is a protocol like this, could you please told me the "standard" of such a protocol.
On most modern computers every USB hub is connected to one xHCI controller (https://wiki.osdev.org/EXtensible_Host_Controller_Interface). At boot the BIOS will build ACPI tables in RAM that the OS will look for in conventional positions. Once the OS finds these tables, it will look at every entry to determine what devices are plugged to the computer including xHCI controllers. As stated on osdev.org
All xHCI controllers will have a Class ID of 0x0C, a Sublcass ID of 0x03, and an Interface value of 0x30. The configuration space for this device will contain two Base Address Registers: BAR0 and BAR1. These two 32-bit address fields combine to create a single 64-bit address that points to the base address of the memory mapped registers for the controller.
The memory mapped register of the xHCI s are then used to send commands to the USB device including commands to get the device descriptor of the USB device. The document on https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/extensible-host-controler-interface-usb-xhci.pdf is the spec for the xHCI. So if you want to really understand how it works under the hood then this is a great place to look at.
By using OID_802_3_PERMANENT_ADDRESS, I can query the mac address of an ethernet card. Intuitively, I think there should exist corresponding OID_802_11_PERMANENT_ADDRESS. However, I find none.
If I direct use OID_802_3_PERMANENT_ADDRESS to query the mac address of 802.11, the result seems correct.
So my question is: Are the mac addresses of 802.3 and 802.11 the same in their respective specifications?
Although the Media Access Control for the Ethernet and wireless link layers are very different due to the nature of collision detection, to keep things simple for the Internet protocols, the MAC address – regardless of the link layer – is always a globally unique 48-bit number. This is significant for Ethernet and 802.11 since routers often aggregate devices onto a single subnet.
So to answer your question, the MAC addresses will not be same.
My device, which is a Linux based IP in-liner is transparent to the network peripherals, that is, no IP address assigned to any of its interfaces.
For the sake of the conversation, let's use ADSL connection as an example, while the device is inspecting the bi-directional traffic, the network is behaving same as if device was not there, attached to the wire (see Physical setup at the attached diagram).
I wonder if I can enclosed that "device" within a Windows machine and have it operated virtually so it still seats inline between the ADSL router and the Windows netwroking interface by using virtual NICs, (or whatever their name is in windows), and inspecting the traffic, same as if it was on a separate physical device, the drawing under "Virtual Setup" in the attached diagram show what I am trying to achieve.
Reading a bit on the VirtualBox docs, seems like binding the right side is relatively simple, perhaps I should have one network adapter set as Bridge Networking and VirtualBox will connect it to the physical NIC on the host machine, and network packets are exchanged directly, circumventing the host operating system's network stack (WinXP in my case).
However, I have no idea how to achieve the left side of my diagram, which requires adding virtual NICs to windows and configure them correctly in a way to make that pipeline possible.
I would appreciate any help.
by the way, if that is not possible with VirtualBox but with other virtualization solution (e.g. VMWare), I would accept the other as well.
components setup diagram http://img715.imageshack.us/img715/810/physicalvsvirtualsetup2.png
It depends on whether you want ( or more if it can ) your linix ( *nix ) inline device to "route" the packets that go through it possibly from one network to another and whether you want this "app" to essentially have no access directly out of your virtual environment ( the green box in your diagram ). If so, what might work is something like:
your "app" is run inside a virtual machine ( say another windows xp instance ) with a NIC configured on a virtual internal or "private" network ( I'm positive both virtualbox and vmware server have this option ) but with the same IP subnet and as your actual network 192.168.1.0
the left side - eth0 - of your *nix device ( which would have to be a virtual machine ) is also set up on this internal / private network
the right side - eth1 - of your *nix device is set up on a bridged network so it has real work access into your real network
This will make it slightly easier to see if traffic / packets are infact going through your *nix device or not, as the app will not have access outside of the virtual internal/private network. NOTE when i say internal/private network I'm not talking about VPNs, just a private network that the host nor your network can reach and the virtual machines can't contact the host or your network.
Without knowing what your *nix device is doing its a little hard. if it can't route or act as a pass through device of some description then the dhcp broadcasts wont get to your dhcp server - which is what I'm guessing your doing something around given that you mentioned it in your diagram.
If your *nix device is a real device then obviously this wont work as I'm assuming its a virtual machine of some description. If this is the case let me know and I'll give some advise on how to work with that situation.
Good luck