I have a Oracle SPARC server with Solaris SPARC 10 OS installed
I have a domestic router/modem box from my ISP in my house. I have a wifi extender in my room which has a RJ45 female socket for ethernet connection. The Wifi extender is configured properly to act as a bridge for machines to connect with my router/modem.
I have setup my NIC card in Solaris 10 with the following commands
dladm show-link
ifconfig e1000g0 plumb up
ifconfig 192.168.0.22 netmask 255.255.255.0 broadcast + up
I have put the IP address of 192.168.0.22 into the /etc/defaultrouter file and again the same IP address in /etc/hostname.e1000g0 file
Next I typed in 'init 6' to reboot Solaris 10.
Once Solaris 10 is up again I can successfully ping the address of 192.168.0.22. But my router obviously needs a password as it is a WPA protected domestic router. This means programs like WGET which needs an URL address to download data doesnt work ATM. Does anyone know what to do to complete the tasks of making my server internet ready. Thanks in advance for any help given to me
Regards
You do not put your Solaris IP address in /etc/defaultrouter
You put the address of the router, which must be in the local network of your Solaris box. It may end with .1 or .250--you need to find out (try ping). For example, in your case it may be 192.168.0.1. After that you also need to configure /etc/resolv.conf with your DNS servers.
Related
I have two machines:
Ubuntu 16.04 server VM (172.18.6.10)
Proxmox VE5 station (192.168.6.30)
they are communicating through a third machine that forwards packets between the two. I want to create a gre tunnel between the two machines and to do that and make it persistent I have edited the /etc/network/interfaces and added a gre interface and tunnel to be made on boot up as the following:
After they were created I have tried to ping one machine from the other to check connectivity, pinging the gre interface IP address (10.10.10.1 and 10.10.10.2). The issue is that when I ping the Proxmox machine from Ubuntu I get no feedback, but when I run tcpdump on gre1 on Porxmox I see that the packets are received and there is a ICMP reply outgoing:
When I run the ping the other way around and check it with tcpdump on the Ubuntu machine I get nothing. I understand that the issue is when packets leave Proxmox to Ubuntu via gre1 and get lost or blocked because Ubuntu can clearly send Proxmox packets but the reply never comes back. How can I fix this?
Check if you have packet forwarding enabled for the kernel of the 3rd machine that you user for the communication of the other 2 machines
Check /etc/sysctl.conf and see if you have this:
net.ipv4.ip_forward = 1
if it's commented (#) uncomment it, save the file and issue a:
sysctl -p
Then try again the pings...
Folks,
I have a Ubuntu machine connected to the Internet through wireless (wlan0), and I am sharing this connection to my Ethernet port (eth1). Then, I have this Ethernet port connected to a switch, and two windows machine connected to the same switch. So the two windows machines have a static IP from the LAN generated from the route generated from wlan0 to eth1, so that I can communicate with all 3 computers at the same time (this works since I can ssh and remote access all 3 computers).
My problem is that I when I run my LCM program (with TTL = 1) on my windows PC, I cannot receive the messages on my Ubuntu machine (meaning that the message should pass through the Ethernet). How can I make sure the UDP messages can be routed back into my Ubuntu machine from the windows machines while the wireless network is running?
This was my solution to the problem (right there on the LCM website):
sudo ifconfig eth1 multicast
sudo route add -net 224.0.0.0 netmask 240.0.0.0 dev eth1
Now all my UDP packets are routed only through eth1. And my shared network (from wlan0) is still intact after this. So all computers have internet at the same time. So great!
I want to find the MAC address of a device. Example: Plug a network cable from my linux mashine to the target device, send some command, receive MAC.
The best solution I have now is to connect a router to the device, wait for it to give out a dhcp lease, connect to the router via ssh and read out the lease table.
I understand that dhcp servers wait for a request from the device and then give out a lease but I would like to actively send some request to the device and get the MAC from the answer directly.
The biggest problem seems to be that without running a dhcp server I can't communicate with the device. Can this be done through a lower layer? Maybe an ARP request?
Thanks!
Ping the other device first and the run the command
arp -a
You can see the MAC address of the device you just pinged.
If you don't know the MAC address of a device the only way to communicate with it is via some sort of broadcast. This implies that there is some software active on the host listening for such a broadcast that will reply. This is how hosts (using ARP) resolve MAC addresses on the local network from an IP address. ARP won't work for you unless you know the IP address.
If you just have a device with no protocol support you're stuck.
If you're using linux, there is wireshark (or the CLI version tshark):
sudo apt-get install tshark
sudo tshark -i eth0
You will see every packet your laptop or the attached device is sending over that ethernet interface. Assuming the device is powered on, you will probably see the MAC address you are looking for somewhere in all of the low level network protocol spew. If you aren't getting much spew, try re-plugging the ethernet cable. (Sorry; I came here looking for a better answer myself)
We solved this by listening for packets from the target mashine and extracting the mac address from the first packet we get.
Thanks for all the answers though!
I am running a Windows 8 VM inside of vmware Fusion. It runs inside a Mac running OSX 10.10 (Yosemite). The VM has a computer name of "Proud". When I ping the VM from within itself, i.e. ping -a 192.168.0.138 I get a response like:
Pinging Proud [192.168.0.138] with 32 bytes of data:
Reply from 192.168.0.138: bytes=32 time<1ms TTL=128
However whenever I ping Proud from Yosemite, i.e. ping Proud I get a response like:
PING proud (199.101.28.130): 56 data bytes
64 bytes from 199.101.28.130: icmp_seq=0 ttl=46 time=418.646 ms
The VM is using bridged networking.
Why does Proud resolve to that IP address? It is not correct and means I am unable to use the hostname (a necessity) so that I can connect to it from the Mac.
First, test and check with IP_address typed for ping from OSX 10.10 <host> terminal, so as to be independent of any DNS-service, that is responsible for a hostname translation of your <hostname> to a pre-configured IP_adress
Second, You say bridged -- thus check, that the VM has the very same network-part of the IP_address ( boundary is given by non-zero bits in subnet-mask
Check details with ifconfig resp. ipconfig
-------------------------|-----------------------------|||--------|||.|||.|||.|||
VM/w8 connected to VMnet? has IP_address := 192.168.0.??? subnet ???.???.???.???
RM/OSX connected to VMnet? has IP_address := 192.168.0.??? subnet ???.???.???.???
EDIT#12014-08-20 15:30 [UTC+0000]:
-------------------------?-----------------------------???--------255.255.255.0
-------------------------|-----------------------------|||
Best to post PrintScreens from {OSX|w8} terminals {ping|ipconfig|ifconfig} and the setup of VMnet
This seems to be a 'feature' of Mac OS. If I attempt to ping any hostname it will return the ping from this IP address - even if the hostname is fictional. I do not know why OS X does this.
This is called DNS hijacking and is done by a lot of ISPs out there to redirect you on incomplete or wrong browser address inputs and show you these custom pages with advertisment 'Hey, we couldn't find your webpage Aple.com but maybe you look for Apple.com?'
Maybe this is whats happening here. Btw, ISPs break RFCs here.
You need to check on your own /etc/host file. See if you might have done any changes to this file, to indicate the machine "Proud" comes as 192.168.0.138 or x.x.x.130? Next thing to ensure (user3666197 is actually right), you need to check on ifconfig to check if you have any connection have the IP address pointing to x.x.x.130 or x.x.x.138.
Last but not least, is there any virtual appliance or instance running of "proud" which might have caused confusion as it is possible for any virtual appliance or instance to get a IP address from the same segment as well, hence having "two" machines on the network?
Hope this helps. Check on your WINS config too...
How do I set an IP address for a TUN interface on OSX? I cannot figure out how to set up an ip address for my interface without specifying a destination IP. I don't want to do that- I'm want to more or less build a tunnel to an arbitrary address at a later point in time. Prior questions which are unhelpful:
There's a question that has an unclear answer, so I tried following the reference.
This question sets a point to point ip address for a tun device, so it has a destination, which is exactly what I don't want.
On the page for osxtuntap it says:
ifconfig tap0 10.1.2.3 up
I cannot make this work on OSX 10.6 for a TUN interface:
$ sudo ifconfig tun0 10.1.2.3 up
ifconfig: ioctl (SIOCAIFADDR): Destination address required
Adding a netmask doesn't help- OSX seems to demand a destination address:
$ ifconfig tun0 10.0.0.1/24 netmask 255.255.255.0
ifconfig: ioctl (SIOCAIFADDR): Destination address required
For linux, I get how it works. According to this page, you open() the interface, and use the ip command, and do this, and I've done this before with zero issues:
$ ip link set tun0 up
$ ip addr add 10.0.0.1/24 dev tun0
All I want to do is the same thing that I can do in linux.
EDIT:
I'm writing a little UDP tunnel app. Like so:
tun1 -> udp app #1 -> udp tunnel -> udp app #2 -> tun2
If the udp apps are on different computers (let's say local and remote), I'd like to associate their respective tun devices with an ip address, so I can send a packet from local to remote via the tunnel by sending the packet to the ip address of the tun device on the remove machine.
To borrow more from the linux tutorial, the author sets up a tun device on local and remote, associates ips, and runs a simple tunneling app, and then pings the other end of the tunnel:
[remote]# ip link set tun3 up
[remote]# ip addr add 192.168.0.2/24 dev tun3
[remote]$ ./simpletun -i tun3 -s
# server blocks waiting for the client to connect
[local]# ip link set tun11 up
[local]# ip addr add 192.168.0.1/24 dev tun11
[local]$ ./simpletun -i tun11 -c 10.2.3.4
# nothing happens, but the peers are now connected
[local]$ ping 192.168.0.2
By default, tun devices operate in the layer 3 mode, aka point to point. You're asking for layer 2 mode which more closely resembles a generic Ethernet device. Linux calls these tap devices. In OpenBSD you can switch a tun device into layer 2 mode with "ifconfig tun0 link0". The Macintosh tuntaposx driver mimics Linux' device schism; open a tap device instead.
You might want to review https://community.openvpn.net/openvpn/wiki/BridgingAndRouting to determine if you really want tap devices. They add a little overhead. If you just need two boxes to pass IP packets between each other and no bridging or broadcasting to a larger subnet, point to point should be sufficient.
For example, if you have two machines, one we label "local" with a LAN IP address like 192.168.0.12 and another we label "remote" with a LAN IP address like 192.168.1.14, you can assign tunnel IP addresses thusly:
ifconfig tun0 inet 10.0.0.1 10.0.0.2 up
on the local system, and:
ifconfig tun0 inet 10.0.0.2 10.0.0.1 up
on the remote system. Note the reversed perspective on the remote machine. Do not set your point to point addresses to anything on an existing subnet; it will not route properly.
I can't stress this enough: read and re-read the manual pages ("man ifconfig" and "man tun", probably others) until they make sense. My ifconfig examples above may differ slightly from your operating system.
And for another perspective you might look into GRE tunnels as their functionality mirrors what you describe for your program. However, GRE is likely not viable in today's TCP-centric networks nor is it a good idea due to major security issues.
If your goal is to circumvent an overbearing firewall, be aware that many such firewalls block UDP (and especially GRE) packets. In such a case, try SSH interface tunneling to set up tun/tap interfaces and forward packets. You get encryption and optionally compression as well. :)