I think I found a way that a loop can exist in STP, and I'm wondering if there are any known solutions to this.
: +----- wifi -----+
: PC1 PC2
: +----- eth ------+
I have PC1 and PC2 connected via both eth and wifi, such that eth is the Designated Port, and wifi is blocked. Now say there were some over-the-air interference for wifi for 20s to the point where PC1.wifi does not receive a bpdu from PC2.wifi. (Note that neither PC1 nor PC2 know about the interference -- as far as they are concerned, wifi is still up). PC1 will assume that PC2 is no longer connected via wifi, and will set that port to a designated port, and bring it to a forwarding state. Once all of this happens, a multicast packet is received on PC1 via eth. Right at that moment, the wireless noise dies down, and PC1 is able to forward the packet to PC2 via wireless. P2 then forwards the packet to PC1 over eth, and so on and so forth, killing the entire system.
Is there any known way to prevent this? (Note: I am using the built-in linux STP from 3.4).
Related
I interested to capture packets that not designated to local machine on windows (tcp packets) and forward them to other application on other port to handle them.
netsh is not working, my guess is that it is not forwarding the packets because it is not designated to local machine.
For example:
Machine A sends packet to machine C, and the packet is passing through machine B.
I want that machine B will catch the packet(because it is not designated to machine B) and redirect it(without manipolating the packet) to other application (on other local port) to handle them.
Machine B is windows station.
I thought to use winpcap to do so if there is no other option, I am not sure how to do it.
Thank you!
I have connected a PiCAN2 board with raspberry pi running latest Jessie. When I try to send some CAN messages to my PC ( PC is connected via a USB to DB9 CAN interface to the PiCAN2 board) through this PiCAN2 using the can-utils, it runs into ERROR-PASSIVE state as soon as I bring the CAN interface up. But, when I enable loopback mode, I am able to send messages and receive them using two different terminal window on the raspberry pi itself. I enabled loopback mode using
sudo /sbin/ip link set can0 type can bitrate 500000 loopback on.
Can some one tell me more about the loopback mode? I want to make sure that my hardware setup for PiCAN2 is correct. Is it possible to confirm that my CAN board is configured correctly because I can send/receive messages using loopback mode?Or this doesn't necessarily mean that it is correct?
I also want to know why I get the ERROR PASSIVE mode - does it indicate that the PiCAN2 is not configured correctly OR does it mean that my USB to DB9 CAN interface has some problem? I am new to this area and any help would be nice. Thank you.
I am trying to modify a ethernet driver using WDK tools provided in Visual Studio 2012.
The samples provided in the WDK are 'miniport adapter' and 'NDIS Light Weight Filter' among others. I am still at the very beginning of driver writing and hence finding it tough to navigate through the code.
I was able to install the miniport adapter after building it in Visual Studio 2012 [Shows up as 'Microsoft Virtual Miniport Adapter' in my network adapters list.] I am able to assign it a IP address and Subnet mask also.[I found out that this does not connect to any physical device on my PC].
I also setup the 'Debug View' software to check the driver messages from my adapter.[ I used 'DbgPrint' statements in the code and then built it.] But, The debug messages are printed repeatedly.
1- Why are the messages printed again and again? The messages are from the 'datapath.c' file of the program and is from the function 'MPSendNetBufferLists'. ['Net Buffer' specifies data sent or received on the network.]
2- I setup Wireshark to capture the data on the adapter and it shows that there are requests from ARP,HTTP,SSDP,MDNS etc coming out of it. I am not able to understand what is actually talking to the adapter? and how can I stop it from talking?
I can use 'ping' to see if there is a connection on the IP address I have assigned to the adapter and it responds with a success telling all packets were sent and there was no packet loss.
My goal is to send and receive 'data' packets via a IP address to this ethernet adapter. ie- I want an application to connect to the IP address assigned to the adapter and talk to it.
3- Can I actually do it with the samples provided in WDK?
Any other suggestions or advice are welcome.
PS- I wasn't able to use the windows debugger built into Visual Studio 2012. I used 2 PCs and was able to connect and install the driver onto the 'target' PC but couldn't do anything with breakpoints etc. The code and Program just did nothing after installing the driver on the 'target' PC. Any suggestions on this?. I thought I could do step-by-step debugging of drivers also.[I know I am wrong].
Thanks
Aditya
NDIS miniport drivers, like many low-level drivers, are meant to talk to hardware. The miniport's responsibility is to take send packets from the OS, translate them into whatever format is required by the hardware, and instruct the hardware to send the packet on the wire.
The WDK could (and in fact, used to) include a real-world sample driver that sends packets on real-world hardware. But this leads to some confusion, since real-world drivers have to deal with lots of hardware-specific details that distract from the main point of the sample. If you starting from a real-world driver, the first thing you'd have to do would be to identify all the hardware-specific bits and rip those out, so you could replace them with your own hardware-specific bits.
Instead, the "netvmini" sample in the WDK is a fake driver. That means it pretends to have actual hardware, but secretly it's all a lie. When the OS sends packets to netvmini, the netvmini driver will simply broadcast those packets to any other netvmini miniport adapters installed on that machine. (In effect, installing 2 netvmini adapters on the same machine simulates what would happen if you had two real adapters plugged into the same Ethernet hub.) So in ASCII-art, this is what happens if you install two netvmini adapters on the same system:
TCPIP TCPIP TCPIP
| | |
Real physical miniport Your netvmini #1 Your netvmini #2
| \ /
[The Internet] [The netvmini virtual hub]
As hopefully the ASCII-art illustrates, your netvmini adapters don't have any path to the Internet. So your driver won't get a "real" IP address that can route to the Internet until you add in details of your hardware. Until then, Windows will just keep trying to send ARPs and HTTP requests that will never go anywhere.
To answer your specific questions:
The messages from MPSendNetBufferLists are printed every time the OS attempts to send a packet. Because the OS thinks that you have a real network connection, the OS will make several attempts to use it. Eventually that should quiet down a bit, when everything comes to the conclusion that this isn't a useful link.
The requests are coming from TCPIP. If you don't want TCPIP to send data, then unbind it from the adapter.
You can definitely send data to the adapter. In fact, you've observed that you're already sending random HTTP packets and etc. But the data won't actually reach the Internet, until you teach the driver how to talk to your real hardware.
If you're sitting there thinking "but I don't have hardware!", then you might want to create a virtual miniport of some sort. Virtual miniports are like netvmini in that they don't have real hardware, but they still do have some way to get the packets off the machine. For example, VPN miniports that operate at layer-2 (like L2TP) will typically install a second driver — an NDIS protocol driver — that sends and receives data from the "real" physical miniport. Then the virtual miniport talks to its protocol whenever it needs to get packets off the machine. The result is:
TCPIP
|
Your virtual miniport
|
Your NDIS protocol
|
The real physical miniport
|
The Internet
There are alternative architectures; for example, a VPN that operates at layer-4 (like SSTP) might decide to open a WSK socket instead of implementing an NDIS protocol driver:
TCPIP
|
Your virtual miniport
|
WSK socket
|
TCPIP
|
The real physical miniport
|
The Internet
Is there a way to find out the IP address of a device that is directly connected to a specific ethernet interface? I.e. given one host, one wired ethernet connection and one second host connected to this wired connection, which layer or protocol below IP could be used to find this out.
I would also be comfortable with a Windows-only solution using some Windows-API function or callback.
(I know that the real way to do this would probably via DHCP, but this is about discovering a legacy device.)
Mmh ... there are many ways.
I answer another network discovery question, and I write a little getting started.
Some tcpip stacks reply to icmp broadcasts.
So you can try a PING to your network broadcast address.
For example, you have ip 192.168.1.1 and subnet 255.255.255.0
ping 192.168.1.255
stop the ping after 5 seconds
watch the devices replies : arp -a
Note : on step 3. you get the lists of the MAC-to-IP cached entries, so there are also the hosts in your subnet you exchange data to in the last minutes, even if they don't reply to icmp_get.
Note (2) : now I am on linux. I am not sure, but it can be windows doesn't reply to icm_get via broadcast.
Is it the only one device attached to your pc ?
Is it a router or another simple pc ?
To use DHCP, you'd have to run a DHCP server on the primary and a client on the secondary; the primary could then query the server to find out what address it handed out. Probably overkill.
I can't help you with Windows directly. On Unix, the "arp" command will tell you what IP addresses are known to be attached to the local ethernet segment. Windows will have this same information (since it's a core part of the IP/Ethernet interface) but I don't know how you get at it.
Of course, the networking stack will only know about the other host if it has previously seen traffic from it. You may have to first send a broadcast packet on the interface to elicit some sort of response and thus populate the local ARP table.
Windows 7 has the arp command within it.
arp -a should show you the static and dynamic type interfaces connected to your system.
Your Best Approach is to install Wireshark, reboot the device wait for the TCP/UDP stream , broadcasts will announce the IP address for both Ethernet ports
This is especially useful when the device connected does not have DHCP Client enabled, then you can go from there.
You can also get information from directly connected networking devices, such as network switches with LDWin, a portable and free Windows program published on github:
http://www.sysadmit.com/2016/11/windows-como-saber-la-ip-del-switch-al-que-estoy-conectado.html
LDWin supports the following methods of link discovery: CDP (Cisco Discovery Protocol) and LLDP (Link Layer Discovery Protocol).
You can obtain the model, management IP, VLAN identifier, Port identifier, firmware version, etc.
I have a application which I suspects to get into problems because network nodes closes its sockets to various other servers it communicates to.
I would like to mimic that behaviour by shutting down one or severel connections that can be seen in netstat.
I'm not an expert in networking on OS level, so this question may be stupid, if so do you have any other suggestion on how to mimic the situation?
Before attempting to simulate the problem, you can diagnose the situation with certainty by using Wireshark or, on *nix, tcpdump. You should be able to capture the traffic and observer whether one of the server(s) is sending you a RST or not.
If you are receiving RST then this may be due to the servers themselves (time-outing and closing the connection while waiting for you to send them a response or data, or closing the connection because of server bugs or load limits), to your ISP's network equipment, or to your own network equipment (e.g. your wireless link going up and down.)
Disconnecting your router, network cable or wireless interface can simulate to various degrees connection issues that you can encounter at any time when talking to your servers. Disconnecting your PC's network cable should simulate a forceful closing of the connection with RST, whereas disconnecting a cable between you and the internet, but not the cable that directly connects your PC (e.g. disconnecting the cable between your router and your cable/DSL modem, or disconnecting the cable/DSL modem from the cable company's cable/telco's wall jack) will allow you to simulate timeout conditions.
You can use TCP View. You can view all the connections from your machine to another, or within the same machine. You can close a connection, thus breaking the connection.