In Windows 7 I'm trying to set up a PPP connection over a direct serial port connection to a remote device. The documentation of the remote device (as well as the documentation I've found for the Windows PPP) indicates that the process should start with a Link Control Protocol packet, but I've discovered (by sniffing the serial line) that the PC, before doing anything else, is transmitting the string "CLIENT" once per second for up to 5 seconds. Only if the PC receives the response "SERVER" will it continue with the LCP initialization.
Does anyone know what level of system functionality is sending this CLIENT string, and how I can disable it. My remote device does not recognize this and refuses to connect based on this.
Update: I have discovered that this string is being initiated by the modem driver mdmhayes.inf as a "DialPrefix", but I have no idea how to update this driver file to eliminate this dial prefix. Thoughts?
Update: I've figured out how to get Windows to stop spitting out the "CLIENT" string (it has to do with changing the DIALPREFIX setting in the mdmhayes.inf file) but I still can't figure out how to make Windows realize it is connected and just move on with establishing the PPP connection. The modem diagnostics keep indicating that unknown strings are received so it doesn't know how to proceed. There should be some setting in the mdmhayes.inf file that tells the system not to wait for anything; it's connected to a wire and that's all that is needed. I just can't figure out what setting to use to make the modem initialization get out of the way to allow the PPP stack to take over.
in options.ttyS0 add:
debug
#19200
115200
192.168.111.1:192.168.111.2
netmask 255.255.255.0
lock
auth
nodefaultroute
nocrtscts
connect /etc/ppp/msclient.sh
msclient.sh :
#!/bin/sh
read -n 5 i
echo "SERVER"
Related
I have an application that is very simple. It sends out UDP packets to a client somewhere else on the network.
The host computer is 192.168.11.66 (Windows 10), the client device is 192.168.11.65 (proprietary device).
The host pc cannot see the client device, however I know that it is on and listening to traffic. When I send UDP packets from the host, I use Wireshark and I do not see the packets being sent out. Instead I see messages from ARP trying to locate the client. I assume because ARP is unsuccessful, the host cancels the sending of the packets.
If I change the destination address of the packets to a broadcast address, all of the packets get sent and I see everything on Wireshark. I need to be able to specify the IP address of the client and have Windows send the packets regardless of whether or not it thinks the client device is on the network or not. The client device looks for UDP traffic specifically addressed to itself and the client device has no way of making itself visible on the network.
Does anyone know how to work around this?
Thank you #Remy: instead to create your own ARP record manually. – Remy Lebeau
I did not realize that I could create manual entries in the ARP. I need to read more about ARP. Adding a manual entry solved my issue. I found that you could do it using ASP -s, or add neighbor using NETSH .
Thanks!
My firm produces some devices with a network interface. The devices are sent with a IP address = 0.0.0.0. The customers plugs the device on the private net in the field and, by using a tiny app written with VB6, discover it and set the correct IP address.
This working by using UDP messages: the app broadcast a "Who's there?" UDP message, read back the answer(s) containing the MAC address of the device(s), and the the user send another UDP message containing the new IP address for target MAC.
Now, for some unknown reasons, one of these device get its IP address set to 127.0.0.2. The problem is that now the VB app can't find (via UDP) the device anymore, making it impossible to change the IP address to a valid one.
Further analisys revealed than if the app is running on Windows XP it sees the device, but if the app is running on Windows 7 the UDP message does'nt arrive to to the "socket" (while Wireshark can see the answer from the device).
Now, there a solution to allow Win7 to let "pass" an UDP message sent from a 127.0.0.2 external address? If yes, we could avoid to ship around the world a replacement device with a correct IP address and all the trouble of phisically mounting it in the field.
Here's a Wireshark capture of the "question" and the "answer" not "detected" by the VB app:
cap.pcapng
Now, for some unknown reasons, one of these device get its IP address set to 127.0.0.2.
You need to fix that.
The 127/8 block is reserved for the "loopback" address (ie. localhost). No packets sent to 127.0.0.2 will leave your systems NIC. Unless there are bugs in the drives (or hardware): this could be the case with WinXP.
I have been reading about setting up a ping tunnel to access the internet when you can only send ICMP packets. Ptunnel seems to be a popular program and the instructions to use it can be found here http://www.cs.uit.no/~daniels/PingTunnel/. The instructions to this program say that you must have both a client and proxy computer.
I do not understand the benefit of a ping tunnel if you must have a proxy computer that can send TCP/IP packets. If I had a computer that could do that, I wouldn't need to set up the tunnel in the first place. Can someone please explain this to me, why is a proxy necessary and if it is how is ping tunneling useful then?
NSNolan
Well, let's assume you have a server (PC running linux for example) in your home where it has total internet access and now you are at work/airport/hotel with your laptop where you have no access to tcp without paying.By setting an icmp or dns tunnel you can "encode" your packets to appear as if they were pings/nslookup, those packets destination is always your server. When the server recieves those pings from you, it "decodes" them and totally understand what you are trying to reach (like a website or download a file as an example).
Then your server serves you and get the information you are seeking and "encode" them again into icmp/nslookup like packets. Those packets can reach you without any problem and once they do, your laptop can decode them back into useful information (just like the ones it would recieve with tcp). That encoding & decoding are what the Ptunnel do. Though I'm not professional I think that is the total point.
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 am working on a project that involves a usb device, through which we will receive ip packets from a remote pc. We assign the remote pc its IP Address. I have been experimenting with sending raw ip packets via several methods:
1 - raw sockets: ping works fine, problems sending tcp
2 - tun/tap W32: I managed to get this working enough to send pings out and get pings back to the phy ethernet device, but could not read them using ReadFile(...) on the driver guid.
3 - winpcap: ping works, out going tcp shows up on wireshark(so I assume it is leaving the pc), but i never get an ack to my syn. Im also worried that if I did get an ack the windows TCP stack would send a rst.
Our goal is to be a transparent pass through from the client pc to the network.
Client <-wrapped ip packet-> [device] <-wrapped ip packet-> WinPC <- IP -> IpNetwork
Its possible that im going about this wrong, seems like this should be easier.
I realize that windows is prob not the ideal OS for this, however I have no control over the OS.
thanks in advance
Fixed my issue with TCP Syn packets not getting acked, turns out I forgot to include the pseudo-header when calculating the TCP header checksum. Now it looks like the tcp handshake completes, so im calling this problem solved. If anyone feels like recomending a better way to accomplish this, feel free to reply. For now looks like we will use the winpcap method.
Update:
For this to work without windows constantly RST'ing tcp connections, you have to enable internet connection sharing(ICS) on the adapter you are sending packets out of. Other than that this ended up working for us.