I'm trying to debug a point-to-point ethernet interface which is not working, and I'm beginning to suspect that things have changed in Windows since I last tried this.
I have built a board with a fixed IP address, and am hooking it up to my laptop for testing. Although the LEDs seem to blink, and my board manages to negotiate a physical connection, when I try to ping it from the PC, it fails. The same PC successfully manages to ping a second PC with a fixed IP address. Let me explain:
The TCP/IPv4 adapter settings on the PC are:
IP address; 192.168.1.5
Network mask: 255.255.255.0
Default Gateway: undefined
The board has:
IP address; 192.168.1.2
Network mask: 255.255.255.0
Default Gateway: 192.168.1.
When I try to ping the board from the PC, I get "Destination host unreachable" some of the time, "Request timed out" the rest I expect if there's a difficulty to always get "Request timed out". The "Destination host unreachable" has me confused. According to Microsoft, this message means nothing is being put out on the wire, and to try the route utility. I tried to "Route add 192.168.1.2 mask 255.255.255.0 0.0.0.0 IF 6", and several other attempts, including using NirSoft's NetRouteView to add a route, and it fails, with "The parameter is incorrect".
When I take a second PC and set it to
IP address; 192.168.1.2
Network mask: 255.255.255.0
Default Gateway: undefined
Then pinging works, which disagrees with the "Destination host unavailable" which I am seeing when the board is attached (the route is there).
Any suggestions?
With a direct, point-to-point connection you can't ping a second PC - where do you connect it to?
Check arp -a to see if the destination IP address has been resolved to a MAC address. If not, the 'board' is likely configured to another IP address or not at all (waiting for DHCP, running zeroconf, ...).
You don't need any routes with both nodes directly connected to each other (or through a switch).
Related
Have a small question..
I got below two ips from my team-mate...
G/W Details: 172.27.180.201 (abc/xyz)
Server Details: 192.168.40.132 (abc/xyz).
When I ping to 201, it goes fine. But ping to 132 didnt work.
Now if I do ssh to 201 and from there I ping to 132, then ping works fine.
So I am thinking what kind of changes I have to do in my Linux-machine(Any static route ??), so that I can directly ping to 132 machine ?
Please help me and let me know if I need to provide any other output details...
Thanks.
The 2 machines (G/W & Server) are in different networks since they are using different private IP address ranges.
Private IP address ranges are as follows:
Class A network 192.168.0.0 - 192.168.255.255 (65,536 IP addresses)
Class B network 172.16.0.0 - 172.31.255.255 (1,048,576 IP addresses)
Class C network 10.0.0.0 - 10.255.255.255 (16,777,216 IP addresses)
Since you can ping G/W:
you are either in the same network and have a class B IP address
you are in a different network which has access to G/W's network by some means (gateway, vpn tunnel etc.)
G/W can ping Server because it has access to Server's network (or Server itself) by some means (gateway, vpn tunnel, firewall etc.)
Disclaimer: I'm not a network expert, my jargon maybe not appropriate :)
172.27.180.201 should do NAT for you.
Or 192.168.40.132 add route.
You can't access 192.168.40.132 only changing your host.
I'd like to log the user's IP address in an OpenShift application. I'm using this access log pattern in my WildFly application server configuration:
<access-log pattern="%{i,X-Forwarded-For} | %A%t%h%l%u%r%s%b%T%I" directory="${jboss.home.dir}" prefix="access" suffix=".log" worker="default"/>
So it basically logs the X-Forwarded-For header.
It works just fine for HTTP connections, but it prints a single - character instead of the client's real IP address when a websocket connection is made.
I've found this bug ticket: https://bugzilla.redhat.com/show_bug.cgi?id=1313395, but there seems to be a commit that fixes the problem.
Is there a way to get the user's real IP address in this situation?
I'm tring to test my Windows Phone 8 app on an actual device, but I need the IP Address of my computer in order to do this. When I type 'ipconfig' in the command prompt, it shows two different IPv4 addresses and I can't tell which is the correct one for my computer that will allow me to test the app on a device.
Command Prompt Output:
Ethernet Adapter vEthernet <Internal Ethernet Port Windows Phone Emulator Internal Switch>:
IPv4 Address......: 169.254.xx.xx
Ethernet Adapter vEthernet <New Virtual Switch>:
IPv4 Address......: 192.168.x.xxx
I'm having a heck of a time getting this app to actually work on a device so if there is anything you see that is off, by all means let me know. My concern in this question though, is which of these is the true IP Address of my computer?
The one starting with 169.254 you can safely ignore. If a device does not receive an IP from any DHCP server within a few seconds, it creates its own, starting with 169.254.x.x, but you can't reach anything with such an IP, nor can anything reach your device.
The second one is the real one in your case. 192.168.x.x means you are part of a private network (but it could also be 10.x.x.x).
If you see multiple IPv4 addresses listed in command prompt as a result of ipconfig command, then the IPv4 address that has Default Gateway is your main or current device or computer IPv4 address.
The first one is your computer's IP address, the second one is for application or OS virtualization.
I'm trying to configure a remote OpenFlow controller over an interface which is also part of the bridge OpenVswitch is managing. I am not using mininet; rather, I have a real VM host (supporting a few qemu-kvm VM's) with a real ethernet port. I want the tap interfaces plus the ethernet port to all be in the same bridge and managed by OVS. The OpenFlow controller resides on a different host, reachable only through the physical ethernet port. So far I have set the remote controller for the bridge as well as put the failure mode into "standalone". Unfortunatley the network is simply not coming up after a reboot (NB: before I lost connectivity I did verify that traffic was flowing between the VM host and the OF controller host on port 6633). It seems that, at a minimum, I need to update the OVS database with an "in-band" setting in some table, but I'm not sure how to do this or if this will be sufficient (along with the things I've already done). With mininet, setting this "in-band" configuration appears to be handled by the "topo" command, but (obviously) I can't do it this way. Does anyone have any experience with this kind of an OVS configuration?
Try this :
#ovs-vsctl add-br br1
#ifconfig br1 10.1.2.11 netmask 255.255.255.0
#ovs-vsctl set-controller br1 tcp:<controller-IP>:6633
You will be able to see the ovs connected to controller.
i've a problem with configuration Qmail + SimScan + SpamAssassin (dovecot + RoundCube) with SPF plugin.
For Spf spam prevention, this system rejects all mail that don't passed SPF test with tool "spfquery" (read SPF explanation for understand my problem).
My Network configuration is:
NAT/Firewall: 10.0.1.1
MailServer: 10.0.1.2
Dns Server : 10.0.1.19
External IP: 212.212.12.12
All modules in my mail server works greatly, also network configuration.
Now i've problem with SPF-rejection or DNSBL, beacuse server IP for incoming mail is 10.0.1.1
Log for smtp server is:
CHKUSER accepted sender: from remote mx5.pippo.com:unknown:10.0.1.1> rcpt <> : sender accepted
qmail-smtpd: spf-reject: HELO(mx5.pippo.com) from 10.0.1.1 MAILFROM:info#pippo.com
Why my tcpserver see mail from 10.0.1.1 and not from mx record of pippo.com?
This is a bad configuration of my NAT or tcpserver/smtp server?
Intersting question. I think something is wrong with your config.
If I understand correctly, your MX record for your domain points to 212.212.12.12, which is the external IP of your router. You have port-forwarding setup on your router, to forward incoming connections on 212.212.12.12:25 to 10.0.1.2:25, which is the IP of your mail server on your private network.
If that's the case, your mail server should still see the connections from the remote IP that they are originating from, it should not look like the connections are coming from 10.0.1.1. Port-forwarding only re-writes the destination IP address on the packets, not the source address.
To confirm this, I did a test on a similar setup that I have at my house. I logged in remotely to a Linux box that I have running on my home network, on an inside IP behind by router, like you have. The Linux box did indeed see that I was coming from my remote IP address, not my home router's IP address.