I am trying to create a VB .Net program that determines if a device is on my wireless LAN (with DHCP enabled) so I can take specific actions depending on the device there or not.
Often when I query the arp cache (using a reverse lookup routine I wrote) to determine if the device's MAC address is present, I fail to find it because the device cache timeout has expired and the device has been removed from arp.
Because the device uses DHCP to get it's IP address, I cannot query the arp cache with a "known" IP address but must use the MAC address to identify the device.
Since I am trying to quickly discover if the device is turned on or off, I want to establish whether my MAC search failure was a result of an expired cache entry or the device really being turned off.
Is there any way, knowing only the device MAC address, to force it to be be known again to arp so I can try searching the arp cache again in 30 seconds to see if an entry appeared?
If you're on the same subnet as the device, and the device will respond to broadcast ICMP pings, you can send a broadcast ping.
In my example, my machine is 129.21.49.41 on the subnet 129.21.49.0/24 (49.0 through 49.255).
The network address for such a network is 129.21.49.0 (first address)
The first assignable address is 129.21.49.1
The last assignable address is 129.21.49.254
The broadcast address is 129.21.49.255.
Here's an example:
angst(~) > ping 129.21.49.255
PING 129.21.49.255 (129.21.49.255): 56 data bytes
64 bytes from 129.21.49.254: icmp_seq=0 ttl=255 time=0.316 ms
64 bytes from 129.21.49.205: icmp_seq=0 ttl=64 time=0.422 ms (DUP!)
64 bytes from 129.21.49.148: icmp_seq=0 ttl=64 time=0.703 ms (DUP!)
64 bytes from 129.21.49.31: icmp_seq=0 ttl=64 time=0.766 ms (DUP!)
64 bytes from 129.21.49.23: icmp_seq=0 ttl=64 time=0.822 ms (DUP!)
64 bytes from 129.21.49.246: icmp_seq=0 ttl=64 time=13.538 ms (DUP!)
^C
Those are all of the machines on my subnetwork that are online that are configured to respond to broadcast pings.
Related
As the title suggest, I want to basically disable the public TCP port and allow plex or other apps to only connect using Tailscale.
Like, I don't want to allow server-public-ip:32400, but instead I wanna do tailscale-server-name:32400.
If I have the port opened in TCP for all sources it works, doesn't work when I remove the ingress rule.
The server pings fine (MagicDNS enabled)
Pinging oracle.hidden-name.ts.net [tailscale-ip] with 32 bytes of data:
Reply from tailscale-ip: bytes=32 time=36ms TTL=64
Reply from tailscale-ip: bytes=32 time=36ms TTL=64
Reply from tailscale-ip: bytes=32 time=38ms TTL=64
Reply from tailscale-ip: bytes=32 time=37ms TTL=64
Ping statistics for tailscale-ip:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 36ms, Maximum = 38ms, Average = 36ms
Figured it out. It won't work with only machine name as it won't resolve HTTP/S, will work with Tailscale IP or the ts.net domain.
If I have the port opened in TCP for all sources it works, doesn't work when I remove the ingress rule.
That likely means the apps connecting to plex are still using the LAN IP address, not the Tailscale IP address. Using MagicDNS might help, the Plex app can be told to go to plex.example.com.beta.tailscale.net.
First of all, I am no developer or network specialist, so please keep things simple. Here's my basic situation:
I have a local server (Apache on Ubuntu 20.04) with several vhosts that need to connect to a Oracle-DB that's installed on a VBox CentOS VM. I do a lot of travel, so the IP I use to connect to the internet changes almost daily, and sometimes I have no internet connection at all. A colleague set my system up to be able to connect via static IP, but unfortunately yesterday something happeneded (vBox went into guru-mode and never got out it) and I had to reinstall and set up the whole thing. But it doesn't work.
As the above mentioned colleague isn't available anymore, I need some external help. Here's what I have:
VBox on Ubuntu, with a host-only adapter set up to have a static IP (192.168.56.10), DHCP off and another bridged adapter
VM with CentOS 7 (system for the Oracle DB)
ifcofig of that VM:
enp0s3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.43.121 netmask 255.255.255.0 broadcast 192.168.43.255
inet6 fe80::5255:9ce9:96c4:7810 prefixlen 64 scopeid 0x20
ether 08:00:27:b2:8b:0d txqueuelen 1000 (Ethernet)
RX packets 43 bytes 4140 (4.0 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 69 bytes 7329 (7.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
enp0s8: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.56.5 netmask 255.255.255.0 broadcast 192.168.56.255
inet6 fe80::6408:c9ff:7c9a:dfb0 prefixlen 64 scopeid 0x20
ether 08:00:27:52:35:de txqueuelen 1000 (Ethernet)
RX packets 1 bytes 590 (590.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 38 bytes 5225 (5.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
enp0s8 is the one that connects to the host-only adapter, and it's configured to have a static IP (192.168.56.10). Yet, after restarting the VM it shows with another IP.
Regardless of this I can't connect via SQLDeveloper (on the host) other than using the IP of enp0s3, and only while I'm connected to the internet (wireless) and the provider doesn't change the IP. It wouldn't be a grate deal to change that IP everytime I start to work, but I have 4 different DBs and sometimes 3 or 4 local websites that have their own config files to connect to the DBs.
Short: I need a way to connect from my host to the Oracle DB on the VM without having to change the configuration files of my vhosts or SQLDeveloper.
I will gladly post any further information you may need, but I'm a new user and apparently not allowed to post pics/screenshots yet.
Thanks.
Skip all this networking futzing and setup port forwards. You can tell VirtualBox to map port 1521 on your host to port 1521 on the vm, so SQL Developer can simply connect to localhost:1521/database in your connection.
I talk about this in more details here
Disclaimer: I'm the product manager at Oracle for SQL Developer.
I am using a Zebra DS457 Scanner to read bar and qr codes via COM-Port (RS232). In my test evironment I used a MSI terminal with Win10 and it worked on the real COM-Port without any problems. But on other devices (Win10 and Win7) there are some issues that the software trigger does not come through and the read information do not get sent back to the computer. When I am using a USB to RS232 FTDI adapter I have no issues at all. But why? First I thought it is Win10 and the legacy support could be better, but the adapter is on all devices better and faster. How is this possible? Maybe a driver specific thing? I am using this adapter link to conrad.de.
An FTDI serial port will impose a minimum latency between the time a character arrives over the wire and when an application can see it, and between the time an application wants to send something and the time it goes over a wire. On older devices, these latencies were a minimum of 1ms each, but I think some newer high speed devices have reduced them to 125us. Further, data which arrives at just the wrong speed sometimes ends up with hundreds of milliseconds of additional latency, for reasons I don't quite understand.
On the other hand, an FTDI device can buffer 256 bytes of data from the wire, or 128 bytes of data from the USB port to be sent over the wire, and process RTS/CTS handshaking, without any software intervention--abilities which are lacking in the UART chips used by PC serial ports. If software gives 128 bytes to an FTDI device, it will start sending it until the remote device deasserts its handshake line, whereupon the FTDI device will stop sending as soon as the current byte is complete; it will then resume transmission as soon as the remote device reasserts handshake. If an FTDI device receives enough data over the wire that its UART would be in danger of overflowing, it will automatically deassert its handshake output without requiring any software intervention. The UART used in PC serial port, by contrast, requires a fast interrupt handler to control or respond to the handshake wires. If an interrupt handler maintains a 4096-byte buffer, it may deassert the handshake wire once that buffer is 75% full, but nothing would deassert the handshake wire if the buffer is less than 75% full and 17 bytes arrive over the wire in quick succession before the UART interrupt handler. Worse, if transmit buffering is enabled, and the PC has fed 16 bytes to the UART for transmission when the remote device deasserts its handshake line, those 16 bytes will be sent out whether or not the remote device is ready to receive them (and based upon the handshake wire, it very well might not be).
Thus, some applications can work much better with an FTDI UART, and some much better with an actual serial port.
I'm using loopback for IPC and data packets are mostly over 4KB. I found that if I send() frequently using two threads(which share the same socket) from a client, sometimes the server only receive 1460(seems to be the MTU of Ethernet?) bytes with a single recv(). What's the reason? Thanks.
I am developing a custom USB HID device with both IN and OUT interrupt endpoints of 64 bytes length each. There are 2 reports (one with report ID 1 and other with report ID 2) with report count of 63 bytes each. When the PC app developed in VC++ sends a 64 byte buffer using WriteFile(), I receive the entire buffer properly at the device on the OUT interrupt endpoint. But when I send a 64 byte buffer from the device to the PC on the IN endpoint, the ReadFile() returns with a value of 4 (timeout). This happens only 2 times when the device is plugged in. After that everything works fine and the PC reads the 64 bytes sent by the device properly.
I am using USBlyzer tool to sniff the USB bus traffic. That software shows that for the first two times the device sends a 64 byte buffer on the interrupt IN endpoint, but it too is not able to show the data in it. And the 3rd time onwards, everything works magically, both PC application and USBlyzer receive and display the 64 bytes buffer contents on the screen.
I am not sure where exactly the problem lies, is it on the PC side code or in the device firmware? Please share your thoughts.