Writing WinXPe NDIS 5.1 device driver. Started with Intel E100 driver source from DDK and adapting to Altera triple-speed ethernet core. Receive packet through scatter gather DMA working well, can see good data. Transmit packet through separate scatter gather DMA claims to be working well. Problem is that ipconfig shows IPv6 only IP address for the NIC. Control Panel, Network Configuration, Internet Protocol, has set static IPv4 IP address and no DHCP. But ipconfig doesn't see it. Can't find any OIDs which appear to tell WinXPe anything about IPv6 versus IPv4. Control Panel, Network Configuration correctly updates itself for ethernet connect and disconnect, but nothing seems to please ipconfig. Where is ipconfig getting its IPv6 information, and how can the driver affect it? Thanks.
The problem was an incomplete implementation of OID_GEN_CURRENT_PACKET_FILTER which inhibited the higher level driver from passing IPv4 packets to/from the driver. Although none of the flag bits in OID_GEN_CURRENT_PACKET_FILTER appears relevant to IPv4 [or IPv6], it mattered. Took a call to Microsoft on my MSDN account to resolve this.
Related
I'm implementing REST client in my Delphi application. The devices, I will be connecting to can be on local or global IPv6 addresses. The devices are having REST server and my application prepares REST URI by using %interface_index at the end of IPv6 address.
I'm observing connection problems when I use interface index(Zone_id) in the ipv6 address when its global.
I'm wondering if there is a way where i can differentiate between these and decide when to use the index or not.
IANA maintains some documents that may help. For example, Internet Protocol Version 6 Address Space
Every IPv6 interface will have a Link-Local address. Packets addressed with Link-Local addresses cannot be routed off the link (hence, Link-Local). Every link will use the same network, so you need to distinguish Link-Local addresses by adding a Zone ID. All Link-Local addresses are in the fe80::/10 network.
Global addresses are in the 2000::/3 range, but there are some address blocks within that range that are not forwardable or globally reachable. See the IANA IPv6 Special-Purpose Address Registry.
You should also study RFC 4291, IP Version 6 Addressing Architecture.
I am new in Wireshark. My question is about Telnet and Eclipse. I have a program who communicate with Telnet. As you see in picture, When I write "a" in Telnet, [97] can be seen in Eclipse console as ASCII.
When i check Wireshark, I can not see any traffic on Telnet. When I filter as "ip.dst==10.10.10.12 && tcp.dstport==5000" or "tcp.port==23" or "Telnet", there is no data in wireshark. I guess, there is a problem in wireshark to see Telnet communication. How can i solve this problem?
Please check the screenshot.
Thanks in advance.Screenshot:
I assume your machine's IP address is 10.10.10.12 and that you are telneting from your machine to itself, right?
I don't know Windows, especially how network data are captured by a program like Wireshark, so I may be completely wrong. But I bet Wireshark on Windows can only see packets that actually use your network adapter (WLAN), i.e. which come from or go to an external machine. Traffic that stay inside your machine is probably invisible to it and to any program of that kind (because it's an limitation of the OS).
Instead of telneting to your WLAN IP address, you may try telneting to localhost (127.0.0.x) and make Wireshark spy on the loopback interface.
I have a IdTCPClient on my application and my firewall inform me about an outgoing connection to 224.0.0.252:5355. In the connection properties the used protocol is UDP.
I've searched for "224.0.0.252" and found that it's an IP multicast address (Link-local Multicast Name Resolution)
Q: Why IdTCPClient try to do that?
As its name suggests, TIdTCPClient only supports TCP not UDP.
UDP 224.0.0.252:5355 is used by Microsoft in modern Windows versions for Link Local Multicast Name Resolution (defined in RFC 4795) as part of their hostname-to-IP lookups when conventional DNS is not available.
When you ask TIdTCPClient to connect to a hostname, it asks the OS to resolve the hostname to an IP address before then connecting to it. Your Windows version is obviously utilizing LLMNR as part of that resolution, and your firewall is picking up on that. That is happening outside of Indy.
The connection to 224.0.0.252:5355 with protocol UDP is used by recent versions of Windows for Link Local Multicast Name Resolution (LLMNR) searching for local network computers.
If you have no local network you may disable LLMNR with a peculiar registry setting.
Create and execute the file "disable-LLMNR.reg" containing:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient]
"EnableMulticast"=dword:00000000
There is a lot of other answers related to this issue, however I believe this is specific.
I am using Delphi XE2 and Indy 10.5.8 and TIdUDPServer
In my local development network I have everything on the same network ip subrange and all connected to the very same Access Point (LinkSys)
I have Androids sendind UDP Broadcast to 255.255.255.255 to request the server ip address that is written in Delphi listening using TIdUDPServer on the port 44444.
The requests get there fine and I can answer back no problem. Works exactly as expected.
However I have noted that in some networks it does not work! It is always simple networks based on an access point, I am not sure but seems that where the problem happens the server PC is connect to the LAN port while the devices are using the wifi, all in the same access point.
Could be the case that the access points do not broadcast the UDP packet by the both LAN and wifi? I know that this kind of broadcast is very limited, but I have not found any information that tell me that in the same access point there is limitations like that.
Is there are ways to test, or workaround?
This solution needs to be strong enough to deal with the many AP out there.
EDIT: For those that want to get the source code for retrieving more information from the network including the broadcast ip as mentioned on the answer below follow this solution, it is all there.
http://www.code10.info/index.php?option=com_content&view=article&id=54:articleretrieve-network-adapter-information&catid=47:cat_coding_algorithms_network&Itemid=78
255.255.255.255 is not the best option for sending UDP broadcasts, and some routers/firewalls do block it unless configured otherwise. The better option is to use the NIC's actual subnet broadcast IP instead. For example, if a UDP socket is bound to local IP 192.168.0.1 with a subnet mask of 255.255.255.0, then the broadcast IP for that subnet is 192.168.0.255.
Most platforms have OS-specific APIs for retrieving a NIC's actual broadcast IP, such as getifaddrs() on POSIX systems, or at least for retrieving the NIC's subnet mask, such as GetAdaptersInfo() and GetAdaptersAddresses() on Windows, so you can calculate the broadcast IP manually.
Retrieving the local broadcast IP(s) may be added to Indy in a future version.
I would like to do a scan in a LAN network to find devices linked.
I'm developping an app in IOS for IPAD
How do I do???
Because those are mobile devices I will assume you want to find devices on a wireless network. Theoretically, since wifi uses shared medium for communication, you can passively listen for traffic flowing through the network and collect data about client without sending any packets. This is something that is commonly referred to as a promiscuous mode. In practice there is 99% chance that the network adapter driver will allow you only to get traffic destined for your MAC address. In that case you will need to resort to actively scanning the network subnet which is not 100% accurate and depending on how the network is implemented can be considered as a possible attack.
The simple way of scanning is sending ICMP requests (ping) to every IP address in the subnet and collecting data from those who send back the echo reply. This is not reliable because some hosts won't respond to ICMP echo request even if they are active. First thing you need is to find out your own IP address and the subnet mask, and calculate the range of possible addresses in your subnet. The range is obtained by using logical AND operator where operands are binary values of your IP address and subnet mask. This is an example from the program that calculates this for typical 192.168.1.1 subnet with 255.255.255.0 subnet mask (192.168.1.1/24 in CIDR notation):
Address: 192.168.1.1 11000000.10101000.00000001 .00000001
Netmask: 255.255.255.0 = 24 11111111.11111111.11111111 .00000000
Wildcard: 0.0.0.255 00000000.00000000.00000000 .11111111
Network: 192.168.1.0/24 11000000.10101000.00000001 .00000000
Broadcast: 192.168.1.255 11000000.10101000.00000001 .11111111
HostMin: 192.168.1.1 11000000.10101000.00000001 .00000001
HostMax: 192.168.1.254 11000000.10101000.00000001 .11111110
Then you would iterate through the range and ping every address. Another thing you can consider is listening for broadcast traffic such as ARP and collecting some of the information that way. I don't know what are you trying to make but you can't get many useful information this way, except for vendor of a host's network adapter.
Check my LAN Scan on Github. It does exactly what you want.
I recently used MMLANScan that was pretty good. It discovers IP, Hostname and MAC Address.
Bonjour have been around since 2002, have a look at it!
I mean, just look at their current tagline:
Bonjour, also known as zero-configuration networking, enables automatic discovery of devices and services on a local network using industry standard IP protocols. Bonjour makes it easy to discover, publish, and resolve network services with a sophisticated, yet easy-to-use, programming interface that is accessible from Cocoa, Ruby, Python, and other languages.