Closed. This question is not about programming or software development. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 3 days ago.
Improve this question
I have 2 Jetson Xavier NX's (Jetpack 4.6.1) that are connecting to IP cameras and running a few Docker containers each that will occasionally (about 25% of the time after rebooting) start increasing network latency for all machines connected to the modem until the entire building can't reach the internet.
I've tried to isolate the problem machine by putting a switch between the router and modem and connecting a second router to the switch to create another network for just the Jetson, and it still blocked access to the internet.
I've tried monitoring network interface statistics when this happens with bmon, but it doesn't show any particularly large data/packet transmissions on any interface
I've tried pausing, stopping, and removing containers
Changing route metrics and removing routes
Deactivating interfaces and trying to connect via a usb-ethernet adapter
Connecting via wifi (both 2.4 and 5g) and ethernet (simultaneously and on their own)
None of these have worked to reliably solve the problem while still allowing the Xavier to access the network/internet and the only thing that seems to affect it is whether or not the IP camera is connected to the Xavier. When the camera isn't connected it's more likely to happen, although not guaranteed, and I haven't seen this issue happen when the camera is connected
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 1 year ago.
Improve this question
I would really appreciate some help :)
Worked from home, connected normally for months.
Went back to work, same HoloLens, same laptop, different Wi-Fi.
Won't connect now - cannot access the device portal (https://192.168.1.110/).
Can normally acces over USB (http://127.0.0.1:10080/).
Tried:
2 networks - office and tethering over mobile
3 browsers
reseting both the HL and the laptop multiple times
I'm using Windows 10.
Any ideas? Thanks :)
As discussed in the comments, the problem was that the IP address had changed: the IP address will be assigned by the network's DHCP server, and is generally persistent once assigned in helpful networks, but when you switch to a different network or different DHCP server the IP address is likely to change.
In home networks or small office networks the DHCP server is probably built into your router. It would be possible to set up an address reservation for the HoloLens in your router's configuration, if you wanted to preserve or change the address, provided both routers use the same IP address range for attached devices.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 5 years ago.
Improve this question
I'm on Linux Mint, never connected to the internet for weeks, and still not connected, doing some python programming (Python 3.6).
I happened to look at the firewall program in it 'report' section and see this
(please not that the firewall was actually set to ALLOW outgoing until I changed it just before this screenshot (it was only set to block incoming). Again, to my knowledge I am not, and have not, been connected to the internet at all and my networking is turned off.:
I'm not a network programmer, but this seems to be showing that these applications have been accessing network ports, correct?
Why would python 3.6 (which I was using) be on this list or ever need to connect to any port at all?? Am I looking at nefarious activity here?
I've heard that software can be placed directly on the hardware of a system. IS it possible that my network interface card could be activated and used without giving any indication?
And again, why would my python 3.6 application be on a firewall report at all?
I'm very concerned about this. Can someone enlighten me?
What you are looking at are mostly servers that are listening for incoming connections. That certainly covers ntpd, cups, ntpd.
It looks like some python programs have also been listening for connections, maybe as part of your programming exercises.
The fact that programs are listening for incoming connections doesn't mean anything has actually connected to them, or even that anything could.
An address of "*" indicates that it's a potential connection, not an actual connection that happened.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 5 years ago.
Improve this question
I am struggling with some problem, probably because there is simply not enough information on the web regarding some specifics I am trying to setup.
I have bought OpenVPN service via tun (routing).
I connect to the OpenVPN server through Raspberry PI (serving me as router), which has two interfaces - eth0 for handling Internet connection and wlan0 for my internal LAN.
My goal is to setup firewall in such way, that I can filter tun-ned income traffic and be able to reach web from LAN behind wlan0. Also - everything should go via VPN.
From the architectural point of view I think it should look like this:
INPUT, FORWARD - dropped,
OUTPUT - allowed,
eth0 allows to flow only packets via default OpenVPN service port,
tun adapter should have all INPUT-related policies applied and should be NAT-ted.
What you think - is this correct thinking? I have managed so far to be able to ping from SSH-ed Raspberry PI into web, but yet no DNS - do I understand correctly that I should have own DNS forwarder? DHCP server is set on Raspberry PI.
Thanks!
I have already solved the issue. For those which are interested - incoming packets from LAN are processed by openvpn client (tun/tap), then passed over internet-facing interface. So it was a mater of setting correct forwarding between interfaces. /etc/resolv.conf just had to been overwritten with global (like Google) DNSes to solve ping-related problem.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 7 years ago.
Improve this question
I am trying to setup openvpn on a server so that I have 2 different tap interfaces (tap0 and tap1) and then a bridge connecting those interfaces. The idea is that a client on tap0 will be able to talk to a client on tap1 and vice-versa.
There is no physical NIC involved in the bridge and the Bridge interface is setup with no ip/netmask/broadcast.
I am able to ping between the 2 when they are both connected however I see no traffic when trying to tcpdump the bridge interface.
I am a bit confused on some things:
Do I need to have an ip configured on the bridge interface at all? I don't quite see the reason for it as all it will do is to make to virtual interfaces talk to each other
Is the fact that the bridge interface does not have an assigned ip/netmask/broadcast the reason I am not able to see the ping traffic on the bridge interface when tcpdumping that interface?
If the answer to number 2 is Yes, I assume that it is not either possible to use iptables to block/allow traffic on that interface, correct? If so is there any other way to accomplish what one would do with iptables on an interface like that?
I guess this wasn't the proper place to put this question but I thought I'd put an update anyway to close the issue.
Turns out that you do not need an assigned ip address on the bridge and it is possible to tcpdump. I happened to be working in containers which made the traffic go outside the vpn when pinging.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
I work with embedded Linux systems that sometimes want to get their IP address from a DHCP server. The DHCP Client client we use (dhcpcd) has limited retry logic. If our device starts up without any DHCP server available and times out, dhcpcd will exit and the device will never get an IP address until it's rebooted with a DHCP server visible/connected. I can't be the only one that has this problem. The problem doesn't even seem to be specific to embedded systems (though it's worse there). How do you handle this? Is there a more robust client available?
The reference dhclient from the ISC should run forever in the default configuration, and it should acquire a lease later if it doesn't get one at startup.
I am using the out of the box dhcp client on FreeBSD, which is derived from OpenBSD's and based on the ISC's dhclient, and this is the out of the box behavior.
See http://www.isc.org/index.pl?/sw/dhcp/
You have several options:
While you don't have an IP address, restart dhcpcd to get more retries.
Have a backup static IP address. This was quite successful in the embedded devices I've made.
Use auto-IP as a backup. Windows does this.
Add to rc.local a check to see if an IP has been obtained. If no setup an 'at' job in the near future to attempt again. Continue scheduling 'at' jobs until an IP is obtained.