New answers tagged

0

You need to remember that an ARP request is a broadcast, and it will go to every host on the broadcast domain. Both PCs, connected to a hub, are on the same broadcast domain. When PC1 has a gateway, and you try to send something (ping) off its network (to PC2), the ping will go to the gateway; PC1 will ARP to find the gateway address (not the PC2 address) ...


0

You should be able to shape your traffic with hfsc : linkshare m2 bandwidth is supposed to be percentual. Here is some documentation : (1, 2, 3) You can try this code for example : iptables -t mangle -A POSTROUTING -p tcp --dport 80 -j CLASSIFY --set-class 1:100 iptables -t mangle -A POSTROUTING -p tcp --dport 80 -j ACCEPT iptables -t mangle -A POSTROUTING ...


2

As fruglemonkey said 1 sec is a bad choice. Try at least 5 sec mean. It will help to have more consistent graph. Of course you can show both data ;-) I can't see anything wrong on your math. But I suggest you to track number of packet/s too. This metric is a lot of important to understand problems. Is not rare you have pps limit reached with low traffic on ...


1

After some research and thanks to the comment of EEAA, it is clear that dividing the available bandwidth percentually is not possible.


2

You should be able to accomplish what you want using this command: ip route add 10.10.0.10 dev eth0:1 src 192.168.111.5 If you enter ip route list you should see the change of src.


0

Turns out that the Dragonboard 410C hardware is simply not capable of being a WPA2-PSK access point host. It can act as a client and the original configuration works with different hardware. Thanks @Zoliton for the time! I really appreciate it.


0

You don't say if you are using a GUI with Asterisk (eg: Elastix or FreePBX) - as this will build your dialplan (and may be creating a weakness). FreePBX had some pretty major security holes allowing attackers to modify the dialplan. Is your code up to date? (Even if it is, exposing the configuration GUI to the internet is a major flaw in the FreePBX ...


-1

I'm quite sure whether i follow your question, but every "router" is going to have (a minimum) of two interfaces to enable routing between two networks. In the event you wish to route to the public internet, you would need a router with one interface connecting to the public WAN and another connecting to the private Lan. However, you will not be able to ...


1

Well it looks like I found an answer - there was a bug in the ti-davinci EMAC driver: Davinci-Linux mailing list notes: Said commit adds a check whether the carrier link is ok. If the link is not ok, the skb is freed and no new dma descriptor added to the rx dma channel. This causes trouble during initialization when the carrier status has not yet ...


0

Your setup looks good. You should look over iptables-persistent to make your firewall start up automatically after VPS reboot. It works really well (it is just a service which start in boot time and modify firewall with saved ruleset).


4

When you set your default policy to DROP and ACCEPT only what you need, this is clearly more secure than allowing everything by default and selectively DROP unwanted traffic types. This at least saves you from securing the services that are not meant to be accessed remotely (from outside your machine or your LAN). Your system is more secure when you expose ...


1

I have found a workaround, not ideal but it works. Basically after the system boots run a script that brings the network interface down and then back up again. Here is the script: #!/bin/bash ifdown enp0s25 sleep 3 ifup enp0s25 I then created a systemd service and a timer to accomplish the rest, I use a timer to run the service 45 seconds after the ...


0

For RHEL7 in /etc/sysconfig/network-scripts/ifcfg-* you may have: ETHTOOL_OPTS="-K ${DEVICE} gso off gro off tso off" if more options then use like ETHTOOL_OPTS="-K ${DEVICE} gso off;-K ${DEVICE} gro off;-K ${DEVICE} tso off" you have to have naturally DEVICE defined in your ifcfg file. No rc.local nor extra ifup scripts needed. Easy to you in generic ...


0

I feel you are mixing couple of things here. As a one-liner, adding the tap interface/vxlan-interface to a linux bridge is no different from adding a physical interface (just that the other end of the interface is different) More detailed answer, based on my inference of your question: The vxlan interface that you have created provides the vxlan tunnel ...


0

As I am also toying around with hostapd I have tested your config. Starting from my (working) config I narrowed it down to two changes: add a channel for auth_algs use value 3 (instead of 1) Thereafter I can connect from another client to this AP and airport on MacOS reports the AP as using WPA2: $ airport -s | grep Katzenklo | awk '{print $1, $7}' ...


0

Here is your problem: According to your configuration, Both NIC are using Metric:1 If you want to use ETH1 as the primary NIC, change the Metric to 0. Your Configuration: eth0 Link encap:Ethernet HWaddr 04:01:33:0E: UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 eth1 Link encap:Ethernet HWaddr 04:01:33:0E: UP BROADCAST RUNNING ...


0

You may try adding the nodefaultroute option in your pptp server's options lists (and also remove defaultroute option), which will prevent the client's to set default gateway to pptp server, when connected. nodefaultroute Disable the defaultroute option. The system administrator who wishes to prevent users from creating default routes with pppd ...


0

Add an iptables rule that will reference your PPTP-server internal interface (facing the LAN) that VPN clients will match. Probably with the VPN IP addresses pool you are using for your PPTP server. In order to reach your LAN SMB servers VPN client's packet will need to cross your VPN server's LAN interface, there you will filter them out.


1

You can add the interfaces that should not come up on boot on a new file /etc/network/interfaces.noboot, then bring them up when needed with: sudo ifup -i /etc/network/interfaces.noboot -v eth1


0

To answer your question, yes. I ran a sample rule on my Debian box... iptables -t nat -A PREROUTING -i xenbr0 -p tcp --dport 64000:65000 -j DNAT --to 172.16.10.10:61000-62000 ... which produced no output, indicating success. I'm running kernel 3.16.0-4-amd64. Checking the NAT rule via iptables -t nat -vnL PREROUTING, I see the rule is listed... DNAT ...


0

Your routing table is in play here. Your proxy is located on an Internet-routable IP address. Your eth0 interface is configured with an Internet-routable IP address as well, likely with a default route pointed to your WAN gateway (Comcast, AT&T, etc.). Your eth1 interface is configured with a non-Internet routable IP address. What's happening is your ...


2

You'll have to add DEFROUTE=no To all the interfaces that should not have the default route. In your case, adding DEFROUTE=no to /etc/sysconfig/network-scripts/ifcfg-eth1 should do the trick. Alternatively, instead of setting GATEWAY in /etc/sysconfig/network you can set it in /etc/sysconfig/network-scripts/route-eth0 instead. I.e. echo 0.0.0.0/0 via ...


4

A wrong boardcast IP would not affect reachability of addresses outside the network/broadcast address range. However, IPs inside that range will be treated as locals and they will not be routed at all. In your specific case, this means that .96 - .255 IPs are not visible from your servers. However, all other IPs outside your local range (.0 - .255) can be ...


3

You need to add a route for the 192.168.2.0/24 network in your firewall. It should be something like: route add -net 192.168.2.0/24 gw 192.168.1.121 Your firewall has no idea where to send a packet when it is coming from 192.168.2.0/24 network. The server can ping the firewall because it is directly connected over 192.168.1.121. Actually, when you try to ...


4

Today, for a relatively modern Linux distro I would initially try to use the ip command ip link show and then filter it's output to get a list of interfaces. You can also use ifconfig -a but newer releases of some distros are nolonger installing this by default. Similarly netstat -i may be useful. You can use the iwconfig command to determine if an ...


0

auto=ondemand means "trigger when there is a need for the tunnel based on a packet". So it will load and wait on the first packet, then bring up the tunnel. If you only want to bring it up manually, use auto=add. If you want to have it always on, use auto=start


0

It seems you have hit this bug. Cause A change was made to the openssh package, dealing with Diffie-Hellman Group Exchange. Previously, keys of size 1024 - 8192 could be exchanged. The minimum was raised to 1536 for added security and to avoid the "logjam" vulnerability. However, if used with some 3rd party ssh implementations which only support ...


1

I just hit this issue with a rack of Ubuntu 14.04.3 servers this week, all upgraded to linux-generic-lts-vivid and running the 3.19.0-43 kernel. After flailing for a few days, we solved the problem by downgrading the kernel to 3.16.0-57 (we had the same problem with the 3.19.0-2x kernel that ships with the 14.04.3 amd64 server iso). apt-get remove ...


2

Bear in mind that BIND (and the zone files and such in /etc/bind) acts as a directory of sorts: it lists the hosts that exist in example.com, what their IP addresses are, and that sort of thing. /etc/resolv.conf, on the other hand, tells your machine where to look up information in DNS. Just because a machine is running a nameserver doesn't mean that it has ...


1

You can either remove all nameserver references from your resolv.conf or you can add a specific nameserver 127.0.0.1 to your file. Note that if you add multiple nameserver entries they are tried in the order they are defined. Note also that the maximum is currently three. You should probably read the documentation, resolv.conf(5).


0

From my research, it doesn't look like this is a simple config file problem. Squid has to be compiled using a --enable-ssl flag, and this appears to be fairly difficult with Debian based distros. It looks to me like squid is more ideal for RPM based distros. See here for more info. I'm going to mark this as an answer for now, unless someone posts ...


1

I'm not entirely familiar with the xfrm syntax, but it looks like : When your VPN is not up, you have a default route to the Internet, so you can ping the way you expect Once the VPN comes up, the XFRM rule essentially adds a policy route which sends all traffic through the tunnel to the other end. There is probably an equivalent rule on the other end ...


3

Actually, I think the confusion comes from the fact that those instructions are mixing two topics : Dealing with policy routing Setting up your standard routing table in a best-practice way These three lines ip route add $P1_NET dev $IF1 src $IP1 ip route add $P2_NET dev $IF2 src $IP2 ip route add default via $P1 are there to handle ...


2

The port remains bound because the calling application that is binding to the port does not use the socket option SO_REUSEADDR. You should fix the calling application to do this. In C: int yes = 1; setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, (void *)&yes, sizeof(yes)); This clears itself in the killed application after net.ipv4.tcp_fin_timeout seconds. ...



Top 50 recent answers are included