Re: Network issue

[Reco]

Hi.

On Thu, Aug 30, 2018 at 06:38:50AM -0400, Michael Stone wrote:
> On Thu, Aug 30, 2018 at 07:32:24AM +0300, Reco wrote:
> > On Wed, Aug 29, 2018 at 06:43:00PM -0400, Michael Stone wrote:
> > > On Wed, Aug 29, 2018 at 09:58:47PM +0300, Reco wrote:
> > > > 3) e1000e may be bad, but vmxnet3 will make oom-killer an everyday
> > > > reality. SR-IOV is a way to go.
> > > 
> > > everyday? really? when did you last try this?
> > 
> > Saw the problem with my own eyes yesterday.
> > 
> > Relatively low amount of free RAM (like 64M out of 16G) and a oom killer
> > stack trace containing tcp_sendmsg + some vmxnet3 NICs.
> > 
> > Those RHEL kernels are outright broken then it comes to memory
> > management.
> 
> Well, this is a debian list...

So? The kernel is a kernel, even if it's a RedHat fork.

Besides, I did not bring VMWare into this thread. In fact, VMWare has
nothing to do with OPs problem.

Reco

Re: Network issue

[Michael Stone]

On Thu, Aug 30, 2018 at 07:32:24AM +0300, Reco wrote:

On Wed, Aug 29, 2018 at 06:43:00PM -0400, Michael Stone wrote:

On Wed, Aug 29, 2018 at 09:58:47PM +0300, Reco wrote:
> 3) e1000e may be bad, but vmxnet3 will make oom-killer an everyday
> reality. SR-IOV is a way to go.

everyday? really? when did you last try this?


Saw the problem with my own eyes yesterday.

Relatively low amount of free RAM (like 64M out of 16G) and a oom killer
stack trace containing tcp_sendmsg + some vmxnet3 NICs.

Those RHEL kernels are outright broken then it comes to memory
management.


Well, this is a debian list...

Re: Network issue

[Reco]

Hi.

On Wed, Aug 29, 2018 at 06:43:00PM -0400, Michael Stone wrote:
> On Wed, Aug 29, 2018 at 09:58:47PM +0300, Reco wrote:
> > 3) e1000e may be bad, but vmxnet3 will make oom-killer an everyday
> > reality. SR-IOV is a way to go.
> 
> everyday? really? when did you last try this?

Saw the problem with my own eyes yesterday.

Relatively low amount of free RAM (like 64M out of 16G) and a oom killer
stack trace containing tcp_sendmsg + some vmxnet3 NICs.

Those RHEL kernels are outright broken then it comes to memory
management.

Reco

Re: Network issue

[Reco]

Hi.

On Wed, Aug 29, 2018 at 03:37:52PM -0500, Nicholas Geovanis wrote:
> On Wed, Aug 29, 2018 at 2:00 PM Reco  wrote:
> > On Wed, Aug 29, 2018 at 01:18:52PM -0500, Nicholas Geovanis wrote:
> > > Hi, I've never used OVH. How certain are you that the e1000 network driver
> > > is the correct one?
> > > Under VMWare/ESX the network driver choice can be crucial, for example.
> >
> > 1) You cannot run Xen in VSphere/ESXi.
> 
> I didn't suggest that one could. Only that network driver choice is
> crucial to network performance in a virtual setting. Hence I wrote
> "For example".

And OP is running Xen. So this means real hardware.

Reco

Re: Network issue

[Michael Stone]

On Wed, Aug 29, 2018 at 09:58:47PM +0300, Reco wrote:

3) e1000e may be bad, but vmxnet3 will make oom-killer an everyday
reality. SR-IOV is a way to go.


everyday? really? when did you last try this?

Re: Network issue

[Lee]

> ... I advise to look at your hardware configuration like flow control.
> This line doesn't seem good for me (mind the text in bold):
>
> "Aug 28 15:50:34 ovh-1 kernel: e1000e: enp1s0 NIC Link is Up 100 Mbps Full
> Duplex, *Flow Control: None"*

In general, enabling flow control is a bad idea - more so if qos is enabled.

I saved this snippet because it's a good explanation of why not to
enable flow control (& the snark about the former wife still makes me
grin :)

>From seif...@netcom.com Tue Mar 23 12:58:14 1999
Newsgroups: comp.dcom.lans.ethernet
Subject: Re: 802.3x Flow Control -- Who has it?

802.3x reminds me of my former marriage--at the time, they both seemed like
good ideas. However, in retrospect, neither made a lot of sense. =8^)

Here's an excerpt on the subject (of .3x, not my former marriage), from my
upcoming book, "Make the Switch! A Comprehensive Guide to LAN Switching
Technology":

begin excerpt
It is important to remember that the PAUSE function was designed for a very
specific use at a very specific time‹to prevent buffer overflow for
memory-constrained switches with an input-queued architecture. At the time
the protocol was devised (1995-96), many low-cost switches used an
input-queued approach, and switch memory was relatively expensive. Reducing
the cost of a switch usually meant reducing its memory capacity; by using
PAUSE-style flow control, such a switch could provide a good
price/performance mix and yet avoid frame loss under peak overload
conditions. The PAUSE protocol is less useful today with lower-cost memory
and the popularity of output-queued switches.

In addition, TCP uses frame loss within the network as its indication of
congestion. That is, TCP¹s end-to-end flow control mechanism detects
underlying frame loss, and uses this information to throttle its flow. If
switches prevent frame loss under congestion conditions, TCP will never
recognize the congestion and will continue sourcing data into the network;
in fact, TCP will see a lack of frame loss over time as an indication that
it can increase the offered load, further exacerbating the congestion
problem. If the switches dropped an occasional frame, TCP would throttle
back the offered load and alleviate much of the network congestion with no
need for PAUSE. This is the concept behind the Random Early Discard (RED)
approach to flow control. Implementing link-layer flow control on switches
can actually interfere with the end-to-end flow control.
  -

Regards,
Lee

Re: Network issue

[Nicholas Geovanis]

On Wed, Aug 29, 2018 at 2:00 PM Reco  wrote:
> On Wed, Aug 29, 2018 at 01:18:52PM -0500, Nicholas Geovanis wrote:
> > Hi, I've never used OVH. How certain are you that the e1000 network driver
> > is the correct one?
> > Under VMWare/ESX the network driver choice can be crucial, for example.
>
> 1) You cannot run Xen in VSphere/ESXi.

I didn't suggest that one could. Only that network driver choice is
crucial to network
performance in a virtual setting. Hence I wrote "For example".

> 2) No sane public provider will use VSphere/ESXi for hosting, the costs
> can dim a budget of a small country.

See above. I'm a customer, I'm familiar with the costs.

> 3) e1000e may be bad, but vmxnet3 will make oom-killer an everyday
> reality. SR-IOV is a way to go.

You simply can't get good high-level throughput using e1000 under ESX.
But that wasn't the
point. Instead it was that driver selection and config can be crucial
in a virtual env.

Re: Network issue

[Fekete Tamás]

Dear Kevin,

and just one more thing.
I am beginner with iptables, but your POSTROUTING doesn't seem good as well.

You made a POSTROUTING in the case of VM-s what you manage (they can see
the internet), but there is no source change on IP packets which goes in
the direction of your VM-s. Your current rule works only in two direction,
if any source from any direction is in the 10.0.0.0/24 LAN.

I think you should add there a second postrouting rule.
And for POSTROUTING you should use -i and -o flags instead of -s, because I
am not sure if iptables understands which IP address should be the source
when it makes the masquerade.

But first of all, I think you should check the hardware flow control
setting.

- Tamas Fekete


2018-08-29 21:24 GMT+02:00 Fekete Tamás :

> Dear all,
>
> the explanation of Reco seems quite good for me.
> If you use load generator on your mobile device it could be the reason.
>
> What happens if you use a normal download for a large file? Do you get the
> same result?
>
> If yes, I advise to look at your hardware configuration like flow control.
> This line doesn't seem good for me (mind the text in bold):
>
> "Aug 28 15:50:34 ovh-1 kernel: e1000e: enp1s0 NIC Link is Up 100 Mbps
> Full Duplex, *Flow Control: None"*
>
> See this link:
> https://access.redhat.com/documentation/en-us/red_hat_
> enterprise_linux/5/html/tuning_and_optimizing_red_hat_
> enterprise_linux_for_oracle_9i_and_10g_databases/sect-
> oracle_9i_and_10g_tuning_guide-adjusting_network_
> settings-flow_control_for_e1000_network_interface_cards
>
> Let's see what happens if you reconfigure your network device.
>
> - Tamas Fekete
>
> 2018-08-29 20:58 GMT+02:00 Reco :
>
>> Hi.
>>
>> Please do not top post. This is a mailing list, not a corporate e-mail
>> spamfest.
>>
>> On Wed, Aug 29, 2018 at 01:18:52PM -0500, Nicholas Geovanis wrote:
>> > Hi, I've never used OVH. How certain are you that the e1000 network
>> driver
>> > is the correct one?
>> > Under VMWare/ESX the network driver choice can be crucial, for example.
>>
>> 1) You cannot run Xen in VSphere/ESXi.
>>
>> 2) No sane public provider will use VSphere/ESXi for hosting, the costs
>> can dim a budget of a small country.
>>
>> 3) e1000e may be bad, but vmxnet3 will make oom-killer an everyday
>> reality. SR-IOV is a way to go.
>>
>>
>> Now, to the issue at hand.
>>
>> > On Wed, Aug 29, 2018 at 6:30 AM Kevin DAGNEAUX <
>> kevin.dagne...@fiitelcom.fr>
>> > wrote:
>>
>> Please note that you seem to have "link down" first:
>>
>> > > Aug 28 15:50:32 ovh-1 kernel: e1000e: enp1s0 NIC Link is Down
>>
>> and 'malfunctioning' netfilter rules next.
>>
>> > > Aug 28 15:50:32 ovh-1 kernel: DROPED packets IN=enp1s0 OUT=
>> > > MAC=ZZ:ZZ:ZZ:ZZ:ZZ:ZZ:ZZ:ZZ:ZZ:ZZ:ZZ:ZZ:ZZ:ZZ SRC=YY.YY.YY.YY
>> > > DST=XX.XX.XX.XX LEN=40 TOS=0x00 PREC=0x00 TTL=55 ID=2229 DF PROTO=TCP
>> > > SPT=9610 DPT=80 WINDOW=0 RES=0x00 RST URGP=0
>>
>> Observe 'RST' flag at each and every 'DROPPED' message.
>> I find it highly unlikely that whatever PHP load test you did it
>> involved sending mass amounts of TCP Reset packets.
>>
>> It seems that the following scenario has much higher probability:
>>
>> 1) You fired your load generator application.
>>
>> 2) Your hosting provided immediately got a signal of your typical DOS
>> attack (not to be confused with DDOS) coming from that seems to be a
>> typical mobile phone.
>>
>> 3) DDOS protection kicked in:
>>
>> a) Isolating your server from the network to stop DOS.
>>
>> b) Sending forged TCP RST to your server to break existing connections
>> *and* termninate unneeded Apache workers (or whatever you have there).
>>
>> c) Banning the initiator of DOS (i.e. you on mobile network) temporarily.
>>
>> 4) Real network outage of your server was 2 seconds (time between "link
>> down" and "link up").
>>
>> Reco
>>
>> >
>> >
>> > > Hi,
>> > >
>> > > I've a server in OVH datacenter, on this server i've 7 VMs, on 1 of
>> them
>> > > in run Apache.
>> > > To debug a slow upload (who was ~2Mo/s instead 12Mo/s) i've installed
>> an
>> > > HTML5/PHP speed test application.
>> > > When i use this app, i've no problem in general, but, when a make a
>> speed
>> > > test from a source who have more bandwith than the server (the server
>> is
>> > > limited at 100Mb/s by OVH and i make the test from a 4G+ network
>> where i've
>> > > ~150Mb/s of bandwith), in this case, the DOM0 lost his network
>> connection
>> > > (like the ethernet cable is unplugged) until i reboot the server.
>> > >
>> > > When i check the syslog of DOM0, i see that iptables drop incomming
>> packet
>> > > on port 80 instead of routing them to the VM.
>> > >
>> > > This is my iptables script i use on DOM0 :
>> > >
>> > > #!/bin/bash
>> > >
>> > > IPT="/sbin/iptables"
>> > >
>> > >
>> > > 
>> ###
>> > > # Filter
>> > >
>> > > ## Remise par defaut des regles
>> > > $IPT -t filter -P INPUT   ACCEPT
>> > > $IPT -t 

Re: Network issue

[Fekete Tamás]

Dear all,

the explanation of Reco seems quite good for me.
If you use load generator on your mobile device it could be the reason.

What happens if you use a normal download for a large file? Do you get the
same result?

If yes, I advise to look at your hardware configuration like flow control.
This line doesn't seem good for me (mind the text in bold):

"Aug 28 15:50:34 ovh-1 kernel: e1000e: enp1s0 NIC Link is Up 100 Mbps Full
Duplex, *Flow Control: None"*

See this link:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/5/html/tuning_and_optimizing_red_hat_enterprise_linux_for_oracle_9i_and_10g_databases/sect-oracle_9i_and_10g_tuning_guide-adjusting_network_settings-flow_control_for_e1000_network_interface_cards

Let's see what happens if you reconfigure your network device.

- Tamas Fekete

2018-08-29 20:58 GMT+02:00 Reco :

> Hi.
>
> Please do not top post. This is a mailing list, not a corporate e-mail
> spamfest.
>
> On Wed, Aug 29, 2018 at 01:18:52PM -0500, Nicholas Geovanis wrote:
> > Hi, I've never used OVH. How certain are you that the e1000 network
> driver
> > is the correct one?
> > Under VMWare/ESX the network driver choice can be crucial, for example.
>
> 1) You cannot run Xen in VSphere/ESXi.
>
> 2) No sane public provider will use VSphere/ESXi for hosting, the costs
> can dim a budget of a small country.
>
> 3) e1000e may be bad, but vmxnet3 will make oom-killer an everyday
> reality. SR-IOV is a way to go.
>
>
> Now, to the issue at hand.
>
> > On Wed, Aug 29, 2018 at 6:30 AM Kevin DAGNEAUX <
> kevin.dagne...@fiitelcom.fr>
> > wrote:
>
> Please note that you seem to have "link down" first:
>
> > > Aug 28 15:50:32 ovh-1 kernel: e1000e: enp1s0 NIC Link is Down
>
> and 'malfunctioning' netfilter rules next.
>
> > > Aug 28 15:50:32 ovh-1 kernel: DROPED packets IN=enp1s0 OUT=
> > > MAC=ZZ:ZZ:ZZ:ZZ:ZZ:ZZ:ZZ:ZZ:ZZ:ZZ:ZZ:ZZ:ZZ:ZZ SRC=YY.YY.YY.YY
> > > DST=XX.XX.XX.XX LEN=40 TOS=0x00 PREC=0x00 TTL=55 ID=2229 DF PROTO=TCP
> > > SPT=9610 DPT=80 WINDOW=0 RES=0x00 RST URGP=0
>
> Observe 'RST' flag at each and every 'DROPPED' message.
> I find it highly unlikely that whatever PHP load test you did it
> involved sending mass amounts of TCP Reset packets.
>
> It seems that the following scenario has much higher probability:
>
> 1) You fired your load generator application.
>
> 2) Your hosting provided immediately got a signal of your typical DOS
> attack (not to be confused with DDOS) coming from that seems to be a
> typical mobile phone.
>
> 3) DDOS protection kicked in:
>
> a) Isolating your server from the network to stop DOS.
>
> b) Sending forged TCP RST to your server to break existing connections
> *and* termninate unneeded Apache workers (or whatever you have there).
>
> c) Banning the initiator of DOS (i.e. you on mobile network) temporarily.
>
> 4) Real network outage of your server was 2 seconds (time between "link
> down" and "link up").
>
> Reco
>
> >
> >
> > > Hi,
> > >
> > > I've a server in OVH datacenter, on this server i've 7 VMs, on 1 of
> them
> > > in run Apache.
> > > To debug a slow upload (who was ~2Mo/s instead 12Mo/s) i've installed
> an
> > > HTML5/PHP speed test application.
> > > When i use this app, i've no problem in general, but, when a make a
> speed
> > > test from a source who have more bandwith than the server (the server
> is
> > > limited at 100Mb/s by OVH and i make the test from a 4G+ network where
> i've
> > > ~150Mb/s of bandwith), in this case, the DOM0 lost his network
> connection
> > > (like the ethernet cable is unplugged) until i reboot the server.
> > >
> > > When i check the syslog of DOM0, i see that iptables drop incomming
> packet
> > > on port 80 instead of routing them to the VM.
> > >
> > > This is my iptables script i use on DOM0 :
> > >
> > > #!/bin/bash
> > >
> > > IPT="/sbin/iptables"
> > >
> > >
> > > 
> ###
> > > # Filter
> > >
> > > ## Remise par defaut des regles
> > > $IPT -t filter -P INPUT   ACCEPT
> > > $IPT -t filter -P FORWARD ACCEPT
> > > $IPT -t filter -P OUTPUT  ACCEPT
> > >
> > > ## On purge les tables
> > > $IPT -t filter -F
> > >
> > > ## On autorise lo
> > > $IPT -t filter -A INPUT -i lo -j ACCEPT
> > >
> > > ## On ouvre les ports nécéssaires au DOM0
> > > $IPT -t filter -A INPUT -m tcp -p tcp --dport 22  -j
> > > ACCEPT ## SSH
> > > $IPT -t filter -A INPUT -m udp -p udp --dport 53  -j
> > > ACCEPT ## DNS
> > > $IPT -t filter -A INPUT -m icmp -p icmp --icmp-type 8 -j
> > > ACCEPT ## Ping
> > > $IPT -t filter -A INPUT -s 10.0.0.0/24 -j ACCEPT
> > >
> > > ## On accepte si la connexion est déjà établie
> > > $IPT -t filter -A INPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT
> > >
> > > ## On log ce qui n'a pas été matché par les règles précédente
> > > $IPT -A INPUT -p tcp -j LOG 

Re: Network issue

[Reco]

Hi.

Please do not top post. This is a mailing list, not a corporate e-mail
spamfest.

On Wed, Aug 29, 2018 at 01:18:52PM -0500, Nicholas Geovanis wrote:
> Hi, I've never used OVH. How certain are you that the e1000 network driver
> is the correct one?
> Under VMWare/ESX the network driver choice can be crucial, for example.

1) You cannot run Xen in VSphere/ESXi.

2) No sane public provider will use VSphere/ESXi for hosting, the costs
can dim a budget of a small country.

3) e1000e may be bad, but vmxnet3 will make oom-killer an everyday
reality. SR-IOV is a way to go.


Now, to the issue at hand.

> On Wed, Aug 29, 2018 at 6:30 AM Kevin DAGNEAUX 
> wrote:

Please note that you seem to have "link down" first:

> > Aug 28 15:50:32 ovh-1 kernel: e1000e: enp1s0 NIC Link is Down

and 'malfunctioning' netfilter rules next.

> > Aug 28 15:50:32 ovh-1 kernel: DROPED packets IN=enp1s0 OUT=
> > MAC=ZZ:ZZ:ZZ:ZZ:ZZ:ZZ:ZZ:ZZ:ZZ:ZZ:ZZ:ZZ:ZZ:ZZ SRC=YY.YY.YY.YY
> > DST=XX.XX.XX.XX LEN=40 TOS=0x00 PREC=0x00 TTL=55 ID=2229 DF PROTO=TCP
> > SPT=9610 DPT=80 WINDOW=0 RES=0x00 RST URGP=0

Observe 'RST' flag at each and every 'DROPPED' message.
I find it highly unlikely that whatever PHP load test you did it
involved sending mass amounts of TCP Reset packets.

It seems that the following scenario has much higher probability:

1) You fired your load generator application.

2) Your hosting provided immediately got a signal of your typical DOS
attack (not to be confused with DDOS) coming from that seems to be a
typical mobile phone.

3) DDOS protection kicked in:

a) Isolating your server from the network to stop DOS.

b) Sending forged TCP RST to your server to break existing connections
*and* termninate unneeded Apache workers (or whatever you have there).

c) Banning the initiator of DOS (i.e. you on mobile network) temporarily.

4) Real network outage of your server was 2 seconds (time between "link
down" and "link up").

Reco

> 
> 
> > Hi,
> >
> > I've a server in OVH datacenter, on this server i've 7 VMs, on 1 of them
> > in run Apache.
> > To debug a slow upload (who was ~2Mo/s instead 12Mo/s) i've installed an
> > HTML5/PHP speed test application.
> > When i use this app, i've no problem in general, but, when a make a speed
> > test from a source who have more bandwith than the server (the server is
> > limited at 100Mb/s by OVH and i make the test from a 4G+ network where i've
> > ~150Mb/s of bandwith), in this case, the DOM0 lost his network connection
> > (like the ethernet cable is unplugged) until i reboot the server.
> >
> > When i check the syslog of DOM0, i see that iptables drop incomming packet
> > on port 80 instead of routing them to the VM.
> >
> > This is my iptables script i use on DOM0 :
> >
> > #!/bin/bash
> >
> > IPT="/sbin/iptables"
> >
> >
> > ###
> > # Filter
> >
> > ## Remise par defaut des regles
> > $IPT -t filter -P INPUT   ACCEPT
> > $IPT -t filter -P FORWARD ACCEPT
> > $IPT -t filter -P OUTPUT  ACCEPT
> >
> > ## On purge les tables
> > $IPT -t filter -F
> >
> > ## On autorise lo
> > $IPT -t filter -A INPUT -i lo -j ACCEPT
> >
> > ## On ouvre les ports nécéssaires au DOM0
> > $IPT -t filter -A INPUT -m tcp -p tcp --dport 22  -j
> > ACCEPT ## SSH
> > $IPT -t filter -A INPUT -m udp -p udp --dport 53  -j
> > ACCEPT ## DNS
> > $IPT -t filter -A INPUT -m icmp -p icmp --icmp-type 8 -j
> > ACCEPT ## Ping
> > $IPT -t filter -A INPUT -s 10.0.0.0/24 -j ACCEPT
> >
> > ## On accepte si la connexion est déjà établie
> > $IPT -t filter -A INPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT
> >
> > ## On log ce qui n'a pas été matché par les règles précédente
> > $IPT -A INPUT -p tcp -j LOG --log-prefix "DROPED packets "
> >
> > ## On bloque tout le reste
> > $IPT -t filter -P INPUT DROP
> >
> >
> > 
> > # Nat
> >
> > ## Remise par defaut des regles
> > $IPT -t nat -P PREROUTING  ACCEPT
> > $IPT -t nat -P POSTROUTING ACCEPT
> > $IPT -t nat -P INPUT   ACCEPT
> > $IPT -t nat -P OUTPUT  ACCEPT
> >
> > ## On purge
> > $IPT -t nat -F
> >
> > ### Routage des ports entrants pour la VM "mails"
> > $IPT -t nat -A PREROUTING -d XX.XX.XX.XX -p tcp --dport 22030 -j DNAT --to
> > 10.0.0.30:22   ## SSH
> > $IPT -t nat -A PREROUTING -d XX.XX.XX.XX -p tcp --dport 25-j DNAT --to
> > 10.0.0.30:25   ## SMTP
> > $IPT -t nat -A PREROUTING -d XX.XX.XX.XX -p tcp --dport 587   -j DNAT --to
> > 10.0.0.30:587  ## SMTP SUBMISSION
> > $IPT -t nat -A PREROUTING -d XX.XX.XX.XX -p tcp --dport 465   -j DNAT --to
> > 10.0.0.30:465  ## SMTP SSL
> > $IPT -t nat -A PREROUTING -d XX.XX.XX.XX -p tcp --dport 143   -j DNAT --to
> > 10.0.0.30:143 

Re: Network issue

[Nicholas Geovanis]

Hi, I've never used OVH. How certain are you that the e1000 network driver
is the correct one?
Under VMWare/ESX the network driver choice can be crucial, for example.

On Wed, Aug 29, 2018 at 6:30 AM Kevin DAGNEAUX 
wrote:

> Hi,
>
> I've a server in OVH datacenter, on this server i've 7 VMs, on 1 of them
> in run Apache.
> To debug a slow upload (who was ~2Mo/s instead 12Mo/s) i've installed an
> HTML5/PHP speed test application.
> When i use this app, i've no problem in general, but, when a make a speed
> test from a source who have more bandwith than the server (the server is
> limited at 100Mb/s by OVH and i make the test from a 4G+ network where i've
> ~150Mb/s of bandwith), in this case, the DOM0 lost his network connection
> (like the ethernet cable is unplugged) until i reboot the server.
>
> When i check the syslog of DOM0, i see that iptables drop incomming packet
> on port 80 instead of routing them to the VM.
>
> This is my iptables script i use on DOM0 :
>
> #!/bin/bash
>
> IPT="/sbin/iptables"
>
>
> ###
> # Filter
>
> ## Remise par defaut des regles
> $IPT -t filter -P INPUT   ACCEPT
> $IPT -t filter -P FORWARD ACCEPT
> $IPT -t filter -P OUTPUT  ACCEPT
>
> ## On purge les tables
> $IPT -t filter -F
>
> ## On autorise lo
> $IPT -t filter -A INPUT -i lo -j ACCEPT
>
> ## On ouvre les ports nécéssaires au DOM0
> $IPT -t filter -A INPUT -m tcp -p tcp --dport 22  -j
> ACCEPT ## SSH
> $IPT -t filter -A INPUT -m udp -p udp --dport 53  -j
> ACCEPT ## DNS
> $IPT -t filter -A INPUT -m icmp -p icmp --icmp-type 8 -j
> ACCEPT ## Ping
> $IPT -t filter -A INPUT -s 10.0.0.0/24 -j ACCEPT
>
> ## On accepte si la connexion est déjà établie
> $IPT -t filter -A INPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT
>
> ## On log ce qui n'a pas été matché par les règles précédente
> $IPT -A INPUT -p tcp -j LOG --log-prefix "DROPED packets "
>
> ## On bloque tout le reste
> $IPT -t filter -P INPUT DROP
>
>
> 
> # Nat
>
> ## Remise par defaut des regles
> $IPT -t nat -P PREROUTING  ACCEPT
> $IPT -t nat -P POSTROUTING ACCEPT
> $IPT -t nat -P INPUT   ACCEPT
> $IPT -t nat -P OUTPUT  ACCEPT
>
> ## On purge
> $IPT -t nat -F
>
> ### Routage des ports entrants pour la VM "mails"
> $IPT -t nat -A PREROUTING -d XX.XX.XX.XX -p tcp --dport 22030 -j DNAT --to
> 10.0.0.30:22   ## SSH
> $IPT -t nat -A PREROUTING -d XX.XX.XX.XX -p tcp --dport 25-j DNAT --to
> 10.0.0.30:25   ## SMTP
> $IPT -t nat -A PREROUTING -d XX.XX.XX.XX -p tcp --dport 587   -j DNAT --to
> 10.0.0.30:587  ## SMTP SUBMISSION
> $IPT -t nat -A PREROUTING -d XX.XX.XX.XX -p tcp --dport 465   -j DNAT --to
> 10.0.0.30:465  ## SMTP SSL
> $IPT -t nat -A PREROUTING -d XX.XX.XX.XX -p tcp --dport 143   -j DNAT --to
> 10.0.0.30:143  ## IMAP
> $IPT -t nat -A PREROUTING -d XX.XX.XX.XX -p tcp --dport 993   -j DNAT --to
> 10.0.0.30:993  ## IMAP SSL
> $IPT -t nat -A PREROUTING -d XX.XX.XX.XX -p tcp --dport 9930  -j DNAT --to
> 10.0.0.30:9930 ## IMAP SSL
>
> ### Routage des ports entrants pour la VM "sql"
> $IPT -t nat -A PREROUTING -d XX.XX.XX.XX -p tcp --dport 22020 -j DNAT --to
> 10.0.0.20:22   ## SSH
> $IPT -t nat -A PREROUTING -d XX.XX.XX.XX -p tcp --dport 3306  -j DNAT --to
> 10.0.0.20:3306 ## MariaDB
>
> ### Routage des ports entrants pour la VM "files"
> $IPT -t nat -A PREROUTING -d XX.XX.XX.XX -p tcp --dport 22010 -j DNAT --to
> 10.0.0.10:22   ## SSH
>
> ### Routage des ports entrant pour la VM "web"
> $IPT -t nat -A PREROUTING -d XX.XX.XX.XX -p tcp --dport 22040 -j DNAT --to
> 10.0.0.40:22   ## SSH
> $IPT -t nat -A PREROUTING -d XX.XX.XX.XX -p tcp --dport 80-j DNAT --to
> 10.0.0.40:80   ## HTTP
> $IPT -t nat -A PREROUTING -d XX.XX.XX.XX -p tcp --dport 443   -j DNAT --to
> 10.0.0.40:443  ## HTTPS
>
> ### Routage des ports entrants pour la VM "monitor"
> $IPT -t nat -A PREROUTING -d XX.XX.XX.XX -p tcp --dport 22050 -j DNAT --to
> 10.0.0.50:22   ## SSH
> $IPT -t nat -A PREROUTING -d XX.XX.XX.XX -p tcp --dport 850 -j DNAT --to
> 10.0.0.50:80 ## HTTP
> $IPT -t nat -A PREROUTING -d XX.XX.XX.XX -p tcp --dport 855 -j DNAT --to
> 10.0.0.50:443## HTTPS
>
> ### Routage des ports entrants pour la VM "comm"
> $IPT -t nat -A PREROUTING -d XX.XX.XX.XX -p tcp --dport 22060 -j DNAT --to
> 10.0.0.60:22   ## SSH
> $IPT -t nat -A PREROUTING -d XX.XX.XX.XX -p tcp --dport 5222  -j DNAT --to
> 10.0.0.60:5222 ## Jabber
> $IPT 

Re: Network issue........

[Neal P. Murphy]

On Wed, 14 Sep 2016 09:40:20 +1000
Charlie  wrote:

> On Tue, 13 Sep 2016 19:18:50 -0400 Neal P. Murphy sent:
> 
> > On Wed, 14 Sep 2016 09:00:51 +1000
> > Charlie  wrote:
> > 
> > > On Tue, 13 Sep 2016 09:31:36 -0600 Joe Pfeiffer sent:
> > >   
> > > > > Kernel IP routing table
> > > > > Destination Gateway  Genmask Flags MSS Window irtt Iface
> > > > > 0.0.0.0   10.80.2.85  0.0.0.0 UG 00  0
> > > > > eth0 10.80.2.84  0.0.0.0  255.255.255.252 U  00  0
> > > > > eth0
> > > > >
> > > > > But when I check it through my windows box it comes up as it
> > > > > should, according to my ISP, with the gateway being 10.80.2.86
> > > > >
> > > > > What is happening? Is it allowed to be that slack, one or the
> > > > > other?
> > > > 
> > > > Do you know whether your gateway is doing any sort of network
> > > > address translation?  It seems odd to me that you're getting an
> > > > address range that matches the external address of your modem,
> > > > and that your external address is a 10.x.x.x (since those are all
> > > > non-routable private IPs). I'd expect either the former if no
> > > > translation is being done, or the latter if your external address
> > > > weren't private.  But seeing both at the same time surprises me.
> > > > 
> > > > On my home system, for instance, my comcast cable modem is at
> > > > 10.1.10.1 internally, but 173.163.240.62 externally.
> > > > 
> > > > I have seen DHCP assign different addresses to Windows than to
> > > > Linux, but in your case the gateway box should be grabbing its
> > > > address for itself, and giving your computer the other available
> > > > address.  
> > > 
> > >   After contemplation, my reply is:
> > > 
> > > What can I say?
> > > 
> > > I have no idea about networking and with the previous satellite
> > > system and modem never had the problems I'm experiencing with this
> > > one.
> > > 
> > > Know nothing of network translation or external address.
> > > 
> > > Connecting directly to the modem with a standard Ethernet cat5
> > > cable to a vanilla, up to date Debian testing laptop, get the
> > > result posted.
> > > 
> > > Connecting to the same modem with the same cable to a windows 10
> > > machine, I checked again this morning, because I could get a
> > > connection through the modem after 54 minutes wait.
> > > 
> > > I get: IPv4 address 10.80.2.86
> > > 
> > > Which the person from my ISP was interested in.
> > > 
> > > I get: Default gateway 10.80.2.85
> > > 
> > > I don't know more than that?
> > > 
> > > I have been trying to discover what the problem is with my Satellite
> > > internet connection. Doing this between outages by the NBN Co,
> > > government arm, who own and run it.
> > > 
> > > It's decidedly tricky, and it's not like my Debian system is the
> > > only one having these problems. They are also being experienced by
> > > windows users on the same satellite system.
> > > 
> > > As an aside:
> > > 
> > > Connecting with an Ethernet cable to the wireless router I get:
> > > 
> > > Gateway 192.168.2.1
> > > Destination 192.168.2.0
> > > 
> > > Thanks for taking the time and thinking about this problem I'm
> > > experiencing. I will have to muddle through and just put up the long
> > > wait to get an internet connection after turning on the modem.
> > > 
> > > Charlie  
> > 
> > Might it be related to the different MAC address? Might the ISP lock
> > service to the MAC address it sees, at least for some period of time?
> > 
> > Get the MAC address of your Win10 system and set the NIC of your
> > Debian system to it, for example: ip link set dev eth0 address
> > aa:bb:cc:dd:ee:ff
> > 
> > See if it works any better once you've cloned the MAC address.
> > 
> > N
> > 
> 
> 
>   After contemplation, my reply is:
> 
> The windows system doesn't find the internet connection either.
> 
> I try to connect with Debian by default and after some 30 or 40
> minutes, a couple of reboots of the modem, bring my eth0 connection up
> and down a couple of times. do direct connection to the modem. If no
> connection found.
> 
> Couple up the windows 10 lappy. First through the wireless non
> connection, rebooting the lappy a couple of times, then the Ethernet
> cable through wireless router and then finally direct to the modem.
> 
> Then, because the connection hasn't been found. I return to the Debian
> lappy, knowing now it's not that system and as I work keep trying
> things and after maybe an hour or often more, get onto a connection.
> 
> One day didn't get on for 2 days, but that was a NBN outage for that
> period.
> 
> Thanks for the suggestion.
> Charlie
> 

Try:
  - turn off the modem for 5 minutes (or longer, if needed; it may take longer
for the ISP to 'reset')
  - turn the modem on
  - see if Debian will connect

Does the ISP use DHCP? Or does it use PPPoE? If DHCP, you might try:
  tcpdump -v -i eth0 port 67 or port 68
to see the DHCP 

Re: Network issue........

[Charlie]

On Tue, 13 Sep 2016 19:18:50 -0400 Neal P. Murphy sent:

> On Wed, 14 Sep 2016 09:00:51 +1000
> Charlie  wrote:
> 
> > On Tue, 13 Sep 2016 09:31:36 -0600 Joe Pfeiffer sent:
> >   
> > > > Kernel IP routing table
> > > > Destination Gateway  Genmask Flags MSS Window irtt Iface
> > > > 0.0.0.0   10.80.2.85  0.0.0.0 UG 00  0
> > > > eth0 10.80.2.84  0.0.0.0  255.255.255.252 U  00  0
> > > > eth0
> > > >
> > > > But when I check it through my windows box it comes up as it
> > > > should, according to my ISP, with the gateway being 10.80.2.86
> > > >
> > > > What is happening? Is it allowed to be that slack, one or the
> > > > other?
> > > 
> > > Do you know whether your gateway is doing any sort of network
> > > address translation?  It seems odd to me that you're getting an
> > > address range that matches the external address of your modem,
> > > and that your external address is a 10.x.x.x (since those are all
> > > non-routable private IPs). I'd expect either the former if no
> > > translation is being done, or the latter if your external address
> > > weren't private.  But seeing both at the same time surprises me.
> > > 
> > > On my home system, for instance, my comcast cable modem is at
> > > 10.1.10.1 internally, but 173.163.240.62 externally.
> > > 
> > > I have seen DHCP assign different addresses to Windows than to
> > > Linux, but in your case the gateway box should be grabbing its
> > > address for itself, and giving your computer the other available
> > > address.  
> > 
> > After contemplation, my reply is:
> > 
> > What can I say?
> > 
> > I have no idea about networking and with the previous satellite
> > system and modem never had the problems I'm experiencing with this
> > one.
> > 
> > Know nothing of network translation or external address.
> > 
> > Connecting directly to the modem with a standard Ethernet cat5
> > cable to a vanilla, up to date Debian testing laptop, get the
> > result posted.
> > 
> > Connecting to the same modem with the same cable to a windows 10
> > machine, I checked again this morning, because I could get a
> > connection through the modem after 54 minutes wait.
> > 
> > I get: IPv4 address 10.80.2.86
> > 
> > Which the person from my ISP was interested in.
> > 
> > I get: Default gateway 10.80.2.85
> > 
> > I don't know more than that?
> > 
> > I have been trying to discover what the problem is with my Satellite
> > internet connection. Doing this between outages by the NBN Co,
> > government arm, who own and run it.
> > 
> > It's decidedly tricky, and it's not like my Debian system is the
> > only one having these problems. They are also being experienced by
> > windows users on the same satellite system.
> > 
> > As an aside:
> > 
> > Connecting with an Ethernet cable to the wireless router I get:
> > 
> > Gateway 192.168.2.1
> > Destination 192.168.2.0
> > 
> > Thanks for taking the time and thinking about this problem I'm
> > experiencing. I will have to muddle through and just put up the long
> > wait to get an internet connection after turning on the modem.
> > 
> > Charlie  
> 
> Might it be related to the different MAC address? Might the ISP lock
> service to the MAC address it sees, at least for some period of time?
> 
> Get the MAC address of your Win10 system and set the NIC of your
> Debian system to it, for example: ip link set dev eth0 address
> aa:bb:cc:dd:ee:ff
> 
> See if it works any better once you've cloned the MAC address.
> 
> N
> 


After contemplation, my reply is:

The windows system doesn't find the internet connection either.

I try to connect with Debian by default and after some 30 or 40
minutes, a couple of reboots of the modem, bring my eth0 connection up
and down a couple of times. do direct connection to the modem. If no
connection found.

Couple up the windows 10 lappy. First through the wireless non
connection, rebooting the lappy a couple of times, then the Ethernet
cable through wireless router and then finally direct to the modem.

Then, because the connection hasn't been found. I return to the Debian
lappy, knowing now it's not that system and as I work keep trying
things and after maybe an hour or often more, get onto a connection.

One day didn't get on for 2 days, but that was a NBN outage for that
period.

Thanks for the suggestion.
Charlie

-- 
Registered Linux User:- 329524
***

However mean your life is, meet it and live it; do not shun it
and call it hard names. It is not so bad as you are. It looks
poorest when you are the richest. -Henry David Thoreau

***

Debian GNU/Linux - Magic indeed.

-

Re: Network issue........

[Neal P. Murphy]

On Wed, 14 Sep 2016 09:00:51 +1000
Charlie  wrote:

> On Tue, 13 Sep 2016 09:31:36 -0600 Joe Pfeiffer sent:
> 
> > > Kernel IP routing table
> > > Destination Gateway  Genmask Flags MSS Window irtt Iface
> > > 0.0.0.0   10.80.2.85  0.0.0.0 UG 00  0 eth0
> > > 10.80.2.84  0.0.0.0  255.255.255.252 U  00  0 eth0
> > >
> > > But when I check it through my windows box it comes up as it should,
> > > according to my ISP, with the gateway being 10.80.2.86
> > >
> > > What is happening? Is it allowed to be that slack, one or the
> > > other?  
> > 
> > Do you know whether your gateway is doing any sort of network address
> > translation?  It seems odd to me that you're getting an address range
> > that matches the external address of your modem, and that your
> > external address is a 10.x.x.x (since those are all non-routable
> > private IPs). I'd expect either the former if no translation is being
> > done, or the latter if your external address weren't private.  But
> > seeing both at the same time surprises me.
> > 
> > On my home system, for instance, my comcast cable modem is at
> > 10.1.10.1 internally, but 173.163.240.62 externally.
> > 
> > I have seen DHCP assign different addresses to Windows than to Linux,
> > but in your case the gateway box should be grabbing its address for
> > itself, and giving your computer the other available address.
> 
>   After contemplation, my reply is:
> 
> What can I say?
> 
> I have no idea about networking and with the previous satellite system
> and modem never had the problems I'm experiencing with this one.
> 
> Know nothing of network translation or external address.
> 
> Connecting directly to the modem with a standard Ethernet cat5 cable to
> a vanilla, up to date Debian testing laptop, get the result posted.
> 
> Connecting to the same modem with the same cable to a windows 10
> machine, I checked again this morning, because I could get a connection
> through the modem after 54 minutes wait.
> 
> I get: IPv4 address 10.80.2.86
> 
> Which the person from my ISP was interested in.
> 
> I get: Default gateway 10.80.2.85
> 
> I don't know more than that?
> 
> I have been trying to discover what the problem is with my Satellite
> internet connection. Doing this between outages by the NBN Co,
> government arm, who own and run it.
> 
> It's decidedly tricky, and it's not like my Debian system is the
> only one having these problems. They are also being experienced by
> windows users on the same satellite system.
> 
> As an aside:
> 
> Connecting with an Ethernet cable to the wireless router I get:
> 
> Gateway 192.168.2.1
> Destination 192.168.2.0
> 
> Thanks for taking the time and thinking about this problem I'm
> experiencing. I will have to muddle through and just put up the long
> wait to get an internet connection after turning on the modem.
> 
> Charlie

Might it be related to the different MAC address? Might the ISP lock service to 
the MAC address it sees, at least for some period of time?

Get the MAC address of your Win10 system and set the NIC of your Debian system 
to it, for example:
ip link set dev eth0 address aa:bb:cc:dd:ee:ff

See if it works any better once you've cloned the MAC address.

N

Re: Network issue........

[Charlie]

On Tue, 13 Sep 2016 09:31:36 -0600 Joe Pfeiffer sent:

> > Kernel IP routing table
> > Destination Gateway  Genmask Flags MSS Window irtt Iface
> > 0.0.0.0   10.80.2.85  0.0.0.0 UG 00  0 eth0
> > 10.80.2.84  0.0.0.0  255.255.255.252 U  00  0 eth0
> >
> > But when I check it through my windows box it comes up as it should,
> > according to my ISP, with the gateway being 10.80.2.86
> >
> > What is happening? Is it allowed to be that slack, one or the
> > other?  
> 
> Do you know whether your gateway is doing any sort of network address
> translation?  It seems odd to me that you're getting an address range
> that matches the external address of your modem, and that your
> external address is a 10.x.x.x (since those are all non-routable
> private IPs). I'd expect either the former if no translation is being
> done, or the latter if your external address weren't private.  But
> seeing both at the same time surprises me.
> 
> On my home system, for instance, my comcast cable modem is at
> 10.1.10.1 internally, but 173.163.240.62 externally.
> 
> I have seen DHCP assign different addresses to Windows than to Linux,
> but in your case the gateway box should be grabbing its address for
> itself, and giving your computer the other available address.

After contemplation, my reply is:

What can I say?

I have no idea about networking and with the previous satellite system
and modem never had the problems I'm experiencing with this one.

Know nothing of network translation or external address.

Connecting directly to the modem with a standard Ethernet cat5 cable to
a vanilla, up to date Debian testing laptop, get the result posted.

Connecting to the same modem with the same cable to a windows 10
machine, I checked again this morning, because I could get a connection
through the modem after 54 minutes wait.

I get: IPv4 address 10.80.2.86

Which the person from my ISP was interested in.

I get: Default gateway 10.80.2.85

I don't know more than that?

I have been trying to discover what the problem is with my Satellite
internet connection. Doing this between outages by the NBN Co,
government arm, who own and run it.

It's decidedly tricky, and it's not like my Debian system is the
only one having these problems. They are also being experienced by
windows users on the same satellite system.

As an aside:

Connecting with an Ethernet cable to the wireless router I get:

Gateway 192.168.2.1
Destination 192.168.2.0

Thanks for taking the time and thinking about this problem I'm
experiencing. I will have to muddle through and just put up the long
wait to get an internet connection after turning on the modem.

Charlie
-- 
Registered Linux User:- 329524
***

To succeed in the world it is not enough to be stupid, you must
also be well-mannered. -Voltaire

***

Debian GNU/Linux - Magic indeed.

-

Re: Network issue........

[Joe Pfeiffer]

Charlie  writes:

> Hello Debian Users,
>
> I have a network issue that I find perplexing:
>
> When I do: # netstat -r -n
>
> or 
>
> # route
>
> Kernel IP routing table
> Destination Gateway  Genmask Flags MSS Window irtt Iface
> 0.0.0.0   10.80.2.85  0.0.0.0 UG 00  0 eth0
> 10.80.2.84  0.0.0.0  255.255.255.252 U  00  0 eth0
>
> But when I check it through my windows box it comes up as it should,
> according to my ISP, with the gateway being 10.80.2.86
>
> What is happening? Is it allowed to be that slack, one or the other?

Do you know whether your gateway is doing any sort of network address
translation?  It seems odd to me that you're getting an address range
that matches the external address of your modem, and that your external
address is a 10.x.x.x (since those are all non-routable private IPs).
I'd expect either the former if no translation is being done, or the
latter if your external address weren't private.  But seeing both at the
same time surprises me.

On my home system, for instance, my comcast cable modem is at 10.1.10.1
internally, but 173.163.240.62 externally.

I have seen DHCP assign different addresses to Windows than to Linux,
but in your case the gateway box should be grabbing its address for
itself, and giving your computer the other available address.

Re: Network issue........

[Charlie]

On Tue, 13 Sep 2016 09:54:08 +0100 Darac Marjal sent:

> On Tue, Sep 13, 2016 at 04:26:55PM +1000, Charlie wrote:
> >
> >Hello Debian Users,
> >
> >I have a network issue that I find perplexing:
> >
> >When I do: # netstat -r -n
> >
> >or
> >
> ># route
> >
> >Kernel IP routing table
> >Destination Gateway  Genmask Flags MSS Window irtt Iface
> >0.0.0.0   10.80.2.85  0.0.0.0 UG 00  0 eth0
> >10.80.2.84  0.0.0.0  255.255.255.252 U  00  0 eth0  
> 
> This translates as "For 10.80.2.84 to 10.80.2.87, talk directly to
> the host, otherwise gateway through 10.80.2.85".
> 
> You don't mention how this route has been allocated, though. Are you 
> using DHCP and these routes are being offered to you by a router?
> Have you entered them manually in /etc/network/interfaces?

The gateway is a satellite modem that has been supplied by the national
satellite service.

The Debian Linux testing box declares it, as mentioned above, on the
command line with either of the two commands mentioned above also. 

The windows 10 box, says the IP address of the gateway is different to
the Debian system, which unfortunately I have been quoting, [as above]?
[cringing] Thinking it was right, and obviously not.

The windows 10 box, on the admin command line type: ipconfig/all 
Shows me the DNS, the ipv4 gateway as mentioned etc., etc..

The Linux system uses DHCP, is that a bad thing?

Windows 10 has DHCP enabled as well. Is that a bad thing? Has
autoconfiguration enabled also.

Anyway windows 10 has it right apparently, Debian does not.

So If I want to make a complaint in the future, will have to trouble
shoot it with the windows 10 system.

Obviously no explanation for the different numbers.

Ce la vie. Thanks for the input.

> >
> >But when I check it through my windows box it comes up as it should,
> >according to my ISP, with the gateway being 10.80.2.86  
> 
> Again, you don't detail how Windows has got this information.
> 
> At the moment, the problem could simply be that you mis-typed one or 
> other of the IP addresses when entering them.
> 
> >
> >What is happening? Is it allowed to be that slack, one or the other?



After contemplation, my reply is:

-- 
Registered Linux User:- 329524
***

Getting bored is not allowed. -Eloise

***

Debian GNU/Linux - Magic indeed.

-

Re: Network issue........

[Erwan David]

On Tue, Sep 13, 2016 at 01:20:30PM CEST, Darac Marjal 
 said:
> On Tue, Sep 13, 2016 at 07:07:51AM -0400, rhkra...@gmail.com wrote:
> >On Tuesday, September 13, 2016 04:54:08 AM Darac Marjal wrote:
> >>On Tue, Sep 13, 2016 at 04:26:55PM +1000, Charlie wrote:
> >>>Kernel IP routing table
> >>>Destination Gateway  Genmask Flags MSS Window irtt Iface
> >>>0.0.0.0   10.80.2.85  0.0.0.0 UG 00  0 eth0
> >>>10.80.2.84  0.0.0.0  255.255.255.252 U  00  0 eth0
> >>
> >>This translates as "For 10.80.2.84 to 10.80.2.87, talk directly to the
> >>host, otherwise gateway through 10.80.2.85".
> >
> >I'm not the OP, but maybe I can learn something.
> >
> >I can sort of see where you got the 10.80.2.84--oh, and I was going to say
> >that I don't see where the 10.80.2.87 came from, but, without doing the math,
> >maybe that comes from the 255.255.255.252 netmask?
> 
> Yes. I actually plugged the numbers into http://www.subnet-calculator.com/
> as I'm lazy, but 255.255.255.252 is also written as /2 and it defines a
> subnet where everything but the last 2 bits of the address are the same.
> We're lucky that, in this instance 10.80.2.84 is on the lower boundary of
> this range (Actually, the routing table might enforce that), so the next 4
> (inclusive) hosts make up the range .84 (which would usually be the
> 'network' address), .85 and .86 (which are both 'usable' hosts) and .87
> (which would be the 'broadcast' address).

That's /30 (30 fixed bits) not /2

Re: Network issue........

[Darac Marjal]

On Tue, Sep 13, 2016 at 07:07:51AM -0400, rhkra...@gmail.com wrote:

On Tuesday, September 13, 2016 04:54:08 AM Darac Marjal wrote:

On Tue, Sep 13, 2016 at 04:26:55PM +1000, Charlie wrote:
>Kernel IP routing table
>Destination Gateway  Genmask Flags MSS Window irtt Iface
>0.0.0.0   10.80.2.85  0.0.0.0 UG 00  0 eth0
>10.80.2.84  0.0.0.0  255.255.255.252 U  00  0 eth0

This translates as "For 10.80.2.84 to 10.80.2.87, talk directly to the
host, otherwise gateway through 10.80.2.85".


I'm not the OP, but maybe I can learn something.

I can sort of see where you got the 10.80.2.84--oh, and I was going to say
that I don't see where the 10.80.2.87 came from, but, without doing the math,
maybe that comes from the 255.255.255.252 netmask?


Yes. I actually plugged the numbers into 
http://www.subnet-calculator.com/ as I'm lazy, but 255.255.255.252 is 
also written as /2 and it defines a subnet where everything but the last 
2 bits of the address are the same. We're lucky that, in this instance 
10.80.2.84 is on the lower boundary of this range (Actually, the routing 
table might enforce that), so the next 4 (inclusive) hosts make up the 
range .84 (which would usually be the 'network' address), .85 and .86 
(which are both 'usable' hosts) and .87 (which would be the 'broadcast' 
address).







--
For more information, please reread.


signature.asc
Description: PGP signature

Re: Network issue........

[rhkramer]

On Tuesday, September 13, 2016 04:54:08 AM Darac Marjal wrote:
> On Tue, Sep 13, 2016 at 04:26:55PM +1000, Charlie wrote:
> >Kernel IP routing table
> >Destination Gateway  Genmask Flags MSS Window irtt Iface
> >0.0.0.0   10.80.2.85  0.0.0.0 UG 00  0 eth0
> >10.80.2.84  0.0.0.0  255.255.255.252 U  00  0 eth0
> 
> This translates as "For 10.80.2.84 to 10.80.2.87, talk directly to the
> host, otherwise gateway through 10.80.2.85".

I'm not the OP, but maybe I can learn something.  

I can sort of see where you got the 10.80.2.84--oh, and I was going to say 
that I don't see where the 10.80.2.87 came from, but, without doing the math, 
maybe that comes from the 255.255.255.252 netmask?

Re: Network issue........

[Fabrizio Carrai]

I suppose you are using DHCP: the gw is assigned by the service.

Il 13 set 2016 08:27, "Charlie"  ha scritto:

>
> Hello Debian Users,
>
> I have a network issue that I find perplexing:
>
> When I do: # netstat -r -n
>
> or
>
> # route
>
> Kernel IP routing table
> Destination Gateway  Genmask Flags MSS Window irtt Iface
> 0.0.0.0   10.80.2.85  0.0.0.0 UG 00  0 eth0
> 10.80.2.84  0.0.0.0  255.255.255.252 U  00  0 eth0
>
> But when I check it through my windows box it comes up as it should,
> according to my ISP, with the gateway being 10.80.2.86
>
> What is happening? Is it allowed to be that slack, one or the other?
>
> TIA
> Charlie
> --
> Registered Linux User:- 329524
> ***
>
> Appreciation is a wonderful thing: It makes what is excellent
> in others belong to us as well. -Voltaire
>
> ***
>
> Debian GNU/Linux - Magic indeed.
>
> -
>
>

Re: Network issue........

[Darac Marjal]

On Tue, Sep 13, 2016 at 04:26:55PM +1000, Charlie wrote:


Hello Debian Users,

I have a network issue that I find perplexing:

When I do: # netstat -r -n

or

# route

Kernel IP routing table
Destination Gateway  Genmask Flags MSS Window irtt Iface
0.0.0.0   10.80.2.85  0.0.0.0 UG 00  0 eth0
10.80.2.84  0.0.0.0  255.255.255.252 U  00  0 eth0


This translates as "For 10.80.2.84 to 10.80.2.87, talk directly to the 
host, otherwise gateway through 10.80.2.85".


You don't mention how this route has been allocated, though. Are you 
using DHCP and these routes are being offered to you by a router? Have 
you entered them manually in /etc/network/interfaces?




But when I check it through my windows box it comes up as it should,
according to my ISP, with the gateway being 10.80.2.86


Again, you don't detail how Windows has got this information.

At the moment, the problem could simply be that you mis-typed one or 
other of the IP addresses when entering them.




What is happening? Is it allowed to be that slack, one or the other?

TIA
Charlie
--
Registered Linux User:- 329524
***

Appreciation is a wonderful thing: It makes what is excellent
in others belong to us as well. -Voltaire

***

Debian GNU/Linux - Magic indeed.

-



--
For more information, please reread.


signature.asc
Description: PGP signature

Re: network issue

[Pascal Hambourg]

Kailash a écrit :
 
 I've got two machines at home with Debian (Wheezy) installed: A  B.
 A is a desktop and B is a laptop. A connects to the network via a wired
 connection and B via the wireless. Both have RAM in excess of 1 GB and
 for machine A, I've set up XFCE.
 
 When browsing the internet, I often find that B is much faster than A.
 After entering a url, when I hit enter, the browser just seems to take a
 while to even connect to the destination server.
 
 How should I go about figuring out this issue?

Check DNS resolution.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/521b095b.6080...@plouf.fr.eu.org

Re: network issue

[Kailash]

On Monday 26 August 2013 01:22 PM, Pascal Hambourg wrote:
 Kailash a écrit :

 I've got two machines at home with Debian (Wheezy) installed: A  B.
 A is a desktop and B is a laptop. A connects to the network via a wired
 connection and B via the wireless. Both have RAM in excess of 1 GB and
 for machine A, I've set up XFCE.

 When browsing the internet, I often find that B is much faster than A.
 After entering a url, when I hit enter, the browser just seems to take a
 while to even connect to the destination server.

 How should I go about figuring out this issue?
 
 Check DNS resolution.
 
 

To ease matters, I installed a PDNSD on the same machine and updated the
network configuration to check the local machine.

I guess my next step will be to try out wireshark.

K.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/521b3e25.5060...@gmail.com

Re: network issue

[Zenaan Harkness]

On 8/26/13, Kailash listskail...@gmail.com wrote:
 On Monday 26 August 2013 01:22 PM, Pascal Hambourg wrote:
 Kailash a écrit :
 I've got two machines at home with Debian (Wheezy) installed: A  B.
 A is a desktop and B is a laptop. A connects to the network via a wired
 connection and B via the wireless. Both have RAM in excess of 1 GB and
 for machine A, I've set up XFCE.

 When browsing the internet, I often find that B is much faster than A.
 After entering a url, when I hit enter, the browser just seems to take a
 while to even connect to the destination server.

 How should I go about figuring out this issue?

 Check DNS resolution.

 To ease matters, I installed a PDNSD on the same machine and updated the
 network configuration to check the local machine.

Good move.

 I guess my next step will be to try out wireshark.

Sounds like a good step/useful longer term tool etc.

But you might start with some ping testing and perhaps other tests?
traceroute? Not sure sorry, but I find ping a good basic start. Ping
one domain, check resolv time, change pdnsd config +  reload it, ping
another domain etc.

Also, you are in a great position for comparative config checking:
confirm that B is good, A is bad, then on both A and B:
 cat /etc/resolv.conf
 ifconfig
 route -n

Just some basic comparison checking of course, might give a clue.

Also, have you checked your router/modem/w-a-p config?

Good luck
Zenaan


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caosgnssom6v7ne3+gv1qd7znt7pvy5wggvktautydupbenq...@mail.gmail.com

RE: network issue

[LOwens]

-Original Message-
From: Pascal Hambourg [mailto:pas...@plouf.fr.eu.org] 
Sent: Monday, August 26, 2013 12:53 AM
To: debian-user@lists.debian.org
Subject: Re: network issue

Kailash a écrit :
 
 I've got two machines at home with Debian (Wheezy) installed: A  B.
 A is a desktop and B is a laptop. A connects to the network via a 
 wired connection and B via the wireless. Both have RAM in excess of 1 
 GB and for machine A, I've set up XFCE.
 
 When browsing the internet, I often find that B is much faster than A.
 After entering a url, when I hit enter, the browser just seems to take 
 a while to even connect to the destination server.
 
 How should I go about figuring out this issue?

Check DNS resolution.
You also might try traceroute from each machine and compare the results.
Larry


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
listmas...@lists.debian.org
Archive: http://lists.debian.org/521b095b.6080...@plouf.fr.eu.org




--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/005901cea273$0d1b3a30$2751ae90$@netptc.net

Re: Network issue with WOODY

[Shyamal Prasad]

Robert == Robert Webb [EMAIL PROTECTED] writes:

Robert Hi all, I tried searching the archives with no luck. I
Robert have a standard load of Debian running and am constantly
Robert having problems with the network not responding when
Robert trying to connect to the box. No matter waht I try to hit,
Robert smtp ssh web, it will not respond unless I try and
Robert re-connect many times. Once on of the ports accepts a
Robert copnnection the rest start working also. It is almost like
Robert the NIC is going to sleep.

Do you  have trouble connecting *from* the box? If not, then the NIC
is probably not going to sleep.

What kind of network do you have. The symptoms you list typically
indicate a network problem. What error do you get when you try to
connect? Does it hang? Does it reject the connection? If you wait a
long time does the connection work out? 

Is your system doing some sort of reverse DNS lookup? Make sure your
/etc/hosts file is good, and /etc/resolv.conf has hosts before bind.

I hope this gives you a couple of straws to clutch on. More
details would help us help you.

Cheers!
Shyamal


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Network issue

[Moe Binkerman]

From: Bradley Alexander [EMAIL PROTECTED]
To: Moe Binkerman [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
Subject: Re: Network issue
Date: 17 Jun 2003 00:34:26 -0400
On Mon, 2003-06-16 at 22:25, Moe Binkerman wrote:
 what happens if you just do the ifconfig command and then route? When
The same thing. Usually it takes about two network commands before
things start going awry. I tried on one boot to bring eth2 up with no
default gateway, so it would be on standby, then give a route del
default and a route add default gw yada. Same indications on the route
command after that, 30+ seconds to get a response, no connection to the
outside world. Tried swapping back by hand and got the same thing. Did
not change until I rebooted.
 networking grinds, I generally suspect a DNS problem or a firewall 
problem.
 I would assume restarting networking would bounce your firewall as well. 
Are

Yes. Bouncing the firewall rules as well. Identical rulesets except for
the outside interface is eth2 vice eth0.
 both interfaces static or dhcp? Are you changing your DNS servers when 
you
 tryto swap over?

Both interfaces are static. The comcast one is actually a dhcp address,
but we were using the network information that we got from dhcp. The DNS
servers are universally available ones, like 4.2.2.2, so they remain the
same. And since we are using IP addresses to try to get out, I don't
think it should be using DNS in the first place.
Thanks,



--
--Brad
This might be a dumb question, but are you sure your firewall handles 
whether the changing the default route from eth1 to eth2 properly? Are you 
using the ipmasq package to handle NAT?

Depending on what you are testing you might be the cause of several DNS or 
ident lookups, which could slow down the failure responce. The commands when 
issued, though execute normally and do not hang right?

Interesting information would be what happens when someone on the net tried 
to come inward, can they ping your interfaces, can they ssh or http 
(assuming thats installed on it).

You might try running tcpdump or iptraf (or maybe even ippl, it makes good 
logs, I've found firewall goofs by looking at ippl's logs) and do a bunch of 
pings, etc after making the change and see if that gives you any hints.

_
Tired of spam? Get advanced junk mail protection with MSN 8. 
http://join.msn.com/?page=features/junkmail

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Network issue

[J F]

Here's a wild guess.
Try a soft reboot of just networking and those ethernet cards, like:
/sbin/ifconfig eth0 down
/sbin/ifconfig eth0 up
/etc/init.d/network restart
Bradley Alexander wrote:
Got a networking question. I have this box thats acting as a firewall.
Basically, its a PII/350 running Woody and gShield. eth0 is the external
interface (DSL) and eth1 is the internal interface. When Verizon screwed
him, he got cablemodem as a backup connection. So I added another
interface (all three are 3Com 3C905s).
The problem is that whether I go in and change /etc/network/interfaces
and restart networking or I manually go in and route del default the
Verizon interface and add the Comcast as the default route (using the
network info they gave me, but _not_ using DHCP), networking gets
severely confused (e.g. doing a route command can take 30 seconds or
more, can't pass traffic, etc). Switching back to the original
configuration doesn't help, either. It remains hopelessly confused until
you end up having to reboot. Once you reboot, it comes up normally, with
either interface as the gateway. Since this one of the interfaces is a
backup, I planned to write a script to automate the switchover. If I
have to reboot every time I have to switch, it defeats the purpose.
This should not be normal behavior for networking, but I'm not sure
where to look.
Thoughts?


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Network issue

[Moe Binkerman]

what happens if you just do the ifconfig command and then route? When 
networking grinds, I generally suspect a DNS problem or a firewall problem. 
I would assume restarting networking would bounce your firewall as well. Are 
both interfaces static or dhcp? Are you changing your DNS servers when you 
tryto swap over?


From: Bradley Alexander [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Network issue
Date: 16 Jun 2003 21:18:15 -0400
Got a networking question. I have this box thats acting as a firewall.
Basically, its a PII/350 running Woody and gShield. eth0 is the external
interface (DSL) and eth1 is the internal interface. When Verizon screwed
him, he got cablemodem as a backup connection. So I added another
interface (all three are 3Com 3C905s).
The problem is that whether I go in and change /etc/network/interfaces
and restart networking or I manually go in and route del default the
Verizon interface and add the Comcast as the default route (using the
network info they gave me, but _not_ using DHCP), networking gets
severely confused (e.g. doing a route command can take 30 seconds or
more, can't pass traffic, etc). Switching back to the original
configuration doesn't help, either. It remains hopelessly confused until
you end up having to reboot. Once you reboot, it comes up normally, with
either interface as the gateway. Since this one of the interfaces is a
backup, I planned to write a script to automate the switchover. If I
have to reboot every time I have to switch, it defeats the purpose.
This should not be normal behavior for networking, but I'm not sure
where to look.
Thoughts?
--
--Brad

Bradley M. Alexander|
gTLD SysAdmin, Security Engineer|   storm [at] tux.org

Key fingerprints:
DSA 0x54434E65: 37F6 BCA6 621D 920C E02E  E3C8 73B2 C019 5443 4E65
RSA 0xC3BCBA91: 3F 0E 26 C1 90 14 AD 0A  C8 9C F0 93 75 A0 01 34

I argue very well.  Ask any of my remaining friends.  I can win an argument 
on
any topic, against any opponent.  People know this, and steer clear of me 
at
parties.  Often, as a sign of their great respect, they don't even invite 
me.
-- Dave Barry

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact 
[EMAIL PROTECTED]

_
Help STOP SPAM with the new MSN 8 and get 2 months FREE*  
http://join.msn.com/?page=features/junkmail

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Network issue

[Bradley Alexander]

On Mon, 2003-06-16 at 22:25, Moe Binkerman wrote:
 what happens if you just do the ifconfig command and then route? When 

The same thing. Usually it takes about two network commands before
things start going awry. I tried on one boot to bring eth2 up with no
default gateway, so it would be on standby, then give a route del
default and a route add default gw yada. Same indications on the route
command after that, 30+ seconds to get a response, no connection to the
outside world. Tried swapping back by hand and got the same thing. Did
not change until I rebooted.

 networking grinds, I generally suspect a DNS problem or a firewall problem. 
 I would assume restarting networking would bounce your firewall as well. Are 

Yes. Bouncing the firewall rules as well. Identical rulesets except for
the outside interface is eth2 vice eth0.

 both interfaces static or dhcp? Are you changing your DNS servers when you 
 tryto swap over?

Both interfaces are static. The comcast one is actually a dhcp address,
but we were using the network information that we got from dhcp. The DNS
servers are universally available ones, like 4.2.2.2, so they remain the
same. And since we are using IP addresses to try to get out, I don't
think it should be using DNS in the first place.

Thanks,



-- 
--Brad

Bradley M. Alexander|
gTLD SysAdmin, Security Engineer|   storm [at] tux.org

Key fingerprints:
DSA 0x54434E65: 37F6 BCA6 621D 920C E02E  E3C8 73B2 C019 5443 4E65
RSA 0xC3BCBA91: 3F 0E 26 C1 90 14 AD 0A  C8 9C F0 93 75 A0 01 34

What does Bob Dole think? Bob Dole thinks he's a dufus.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]