On Tue, Aug 15, 2023 at 05:02:49AM +, Albretch Mueller wrote:
> site="download.gluonhq.com"
> date
> time ping "${site}" -c 4
> time traceroute "${site}"
>
> $ site="download.gluonhq.com"
> date
> time ping "${site}" -c 4
> time traceroute "${site}"
> Mon 14 Aug 2023 11:54:19 PM UTC
> PING s3-
site="download.gluonhq.com"
date
time ping "${site}" -c 4
time traceroute "${site}"
$ site="download.gluonhq.com"
date
time ping "${site}" -c 4
time traceroute "${site}"
Mon 14 Aug 2023 11:54:19 PM UTC
PING s3-website.us-east-1.amazonaws.com (54.231.134.85) 56(84) bytes of data.
64 bytes from s3-w
On Sat, Apr 09, 2022 at 12:47:09PM +0100, Brian wrote:
> On Sat 09 Apr 2022 at 08:33:31 +0200, to...@tuxteam.de wrote:
>
> > On Fri, Apr 08, 2022 at 08:52:26PM +0100, Brian wrote:
> >
> > [...]
> >
> > > You didn't like my bus analogy, did you?
> >
> > I did like it. Nevertheless, I thought som
On Sat 09 Apr 2022 at 08:33:31 +0200, to...@tuxteam.de wrote:
> On Fri, Apr 08, 2022 at 08:52:26PM +0100, Brian wrote:
>
> [...]
>
> > You didn't like my bus analogy, did you?
>
> I did like it. Nevertheless, I thought something's missing:
In general, analogies don't really work, do they?
>
On Fri, Apr 08, 2022 at 08:52:26PM +0100, Brian wrote:
[...]
> You didn't like my bus analogy, did you?
I did like it. Nevertheless, I thought something's missing:
> What makes you think that knowing a bus number and destination
> provudes information for where it departs from?
>
> What makes y
On Sat, 26 Oct 2019 00:04:17 +0200
deloptes wrote:
> Celejar wrote:
>
> > I don't get it - IIUC, this sort of thing will work if a given system
> > is always available via a remote connection. In such a case, we can set
> > up the routes so that clients on the local network know to route
> > pac
On Fri, 25 Oct 2019 21:44:44 +0200
deloptes wrote:
> Celejar wrote:
>
> > Furthermore, changing the addressing scheme is insufficient to solve
> > the problem: say the home network uses 10.0.0.0/16, and the VPN is
> > configured to assign the same address to the laptop that it gets when
> > it's
Celejar wrote:
> Furthermore, changing the addressing scheme is insufficient to solve
> the problem: say the home network uses 10.0.0.0/16, and the VPN is
> configured to assign the same address to the laptop that it gets when
> it's connected locally. How do hosts on the local network that want
>
On Fri, 25 Oct 2019 21:35:48 +0200
deloptes wrote:
> Celejar wrote:
>
> > I'm not sure exactly what networking scheme you're describing, but I
> > explained why there's no easy, good solution in the original thread.
> > Basically, the home network uses 192.168.0.0/24, as do other LANS I
> > conn
Celejar wrote:
> I don't get it - IIUC, this sort of thing will work if a given system
> is always available via a remote connection. In such a case, we can set
> up the routes so that clients on the local network know to route
> packets to the given system through the VPN server. But in my case,
Dan Ritter wrote:
> I use a much better supported system called Debian. It did
> require me to spend a bit more on the firewall hardware, but on
> the other hand it is tremendously speedy and configurable.
>
> -dsr-
+1 here
spent 250,- 12y ago for a industrial board pc with 3 network devices. D
> I use a much better supported system called Debian. It did
> require me to spend a bit more on the firewall hardware, but on
> the other hand it is tremendously speedy and configurable.
I like this option as well, but I find it hard to come across
suitable hardware. I need:
- ≥2 ethernet ports
deloptes wrote:
> push "route 10.1.1.0 255.255.255.0"
> push "route 192.168.1.0 255.255.255.0"
as it seems the level is basic these both lines are here (AFAIR) to make it
possible that different PCs in the VPN see each other and that the PC on
the VPN see the home network. This is configurin
Celejar wrote:
> I'm not sure exactly what networking scheme you're describing, but I
> explained why there's no easy, good solution in the original thread.
> Basically, the home network uses 192.168.0.0/24, as do other LANS I
> connect to. My VPN uses 10.0.0.0/24. When the laptop is connected
> l
On Fri, 25 Oct 2019 12:25:27 -0400
Celejar wrote:
> On Fri, 25 Oct 2019 09:13:31 -0400
> Greg Wooledge wrote:
>
> > On Fri, Oct 25, 2019 at 08:56:19AM -0400, Celejar wrote:
> > > Basically, the home network uses 192.168.0.0/24, as do other LANS I
> > > connect to.
> >
> > So change your home n
On Fri, 25 Oct 2019 12:55:32 -0400
Dan Ritter wrote:
> Celejar wrote:
> > On Fri, 25 Oct 2019 10:14:59 -0400
> > Gene Heskett wrote:
> >
> > > On Friday 25 October 2019 09:13:31 Greg Wooledge wrote:
> > >
> > > > On Fri, Oct 25, 2019 at 08:56:19AM -0400, Celejar wrote:
> > > > > Basically, th
Celejar wrote:
> On Fri, 25 Oct 2019 10:14:59 -0400
> Gene Heskett wrote:
>
> > On Friday 25 October 2019 09:13:31 Greg Wooledge wrote:
> >
> > > On Fri, Oct 25, 2019 at 08:56:19AM -0400, Celejar wrote:
> > > > Basically, the home network uses 192.168.0.0/24, as do other LANS I
> > > > connect
On Fri, 25 Oct 2019 10:14:59 -0400
Gene Heskett wrote:
> On Friday 25 October 2019 09:13:31 Greg Wooledge wrote:
>
> > On Fri, Oct 25, 2019 at 08:56:19AM -0400, Celejar wrote:
> > > Basically, the home network uses 192.168.0.0/24, as do other LANS I
> > > connect to.
> >
> > So change your home
On Fri, 25 Oct 2019 09:13:31 -0400
Greg Wooledge wrote:
> On Fri, Oct 25, 2019 at 08:56:19AM -0400, Celejar wrote:
> > Basically, the home network uses 192.168.0.0/24, as do other LANS I
> > connect to.
>
> So change your home network.
I suppose I could, I just didn't feel like doing that just
On 10/25/2019 4:14 PM, Gene Heskett wrote:
> On Friday 25 October 2019 09:13:31 Greg Wooledge wrote:
>
>> On Fri, Oct 25, 2019 at 08:56:19AM -0400, Celejar wrote:
>>> Basically, the home network uses 192.168.0.0/24, as do other LANS I
>>> connect to.
>>
>> So change your home network.
>
> 192.168.0
On Friday 25 October 2019 09:13:31 Greg Wooledge wrote:
> On Fri, Oct 25, 2019 at 08:56:19AM -0400, Celejar wrote:
> > Basically, the home network uses 192.168.0.0/24, as do other LANS I
> > connect to.
>
> So change your home network.
192.168.0.## and 192.168.1.## are the last two blocks I would
On Fri, Oct 25, 2019 at 08:56:19AM -0400, Celejar wrote:
> Basically, the home network uses 192.168.0.0/24, as do other LANS I
> connect to.
So change your home network.
On Fri, 25 Oct 2019 09:25:41 +0200
deloptes wrote:
> Celejar wrote:
>
> > We had a long thread about this back in April [0], but no good solution
> > was presented, so I decided to design a framework to address this
> > problem. It's probably overkill, but it was a good opportunity to
> > practi
Celejar wrote:
> We had a long thread about this back in April [0], but no good solution
> was presented, so I decided to design a framework to address this
> problem. It's probably overkill, but it was a good opportunity to
> practice my Perl in general, and learn how to write a web application
>
On Tue, 16 Apr 2019 11:03:14 -0400
Celejar wrote:
> Hi,
>
> I've been bedeviled by this question for a while, but have been unable
> to figure out a clean, non-hackish solution. It may be an XY problem ...
>
> I have a system (laptop, running Debian) that is sometimes connected
> directly to my
On Thu, 18 Apr 2019 10:43:55 -0400
Michael Stone wrote:
> On Thu, Apr 18, 2019 at 10:41:18AM -0400, Celejar wrote:
> >> Alternatively, for internal-only stuff, you can use ULAs. IPv6
> >
> >The context of our discussion is seamless and collision-free host access
> >across a VPN, not "internal-onl
On Sun, 21 Apr 2019 06:22:24 +1200
Richard Hector wrote:
...
> I found the #ipv6 channel on freenode to be extremely helpful - as long
> as you can cope with frequent digressions into ice hockey :-)
Thanks! I'll be sure to check it out if I seriously consider making the
move to IPv6.
> Richard
On 18/04/19 5:36 AM, Celejar wrote:
> On Thu, 18 Apr 2019 04:49:56 +1200
> Richard Hector wrote:
>
>> On 18/04/19 12:15 AM, Celejar wrote:
>>> Currently, my LAN is 192.168.0.0/24, which is also the addressing
>>> scheme of some of the networks out of my control that I'm setting up a
>>> VPN link
break.
>
This is correct as far as it goes. If corps merge and their internal IP
addresses overlap, they sort it out. There is no addressing based solution
other than creative routing.
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Nicholas Geovanis wrote:
> On Thu, Apr 18, 2019 at 7:57 AM Michael Stone wrote:
>
>>
>> No, the ULA is the IPv6 equivalent of RFC1918 space--you can use it
>> internally without central registration by choosing a subnet from
>> fd00::/8. The space i
On Thu, Apr 18, 2019 at 10:41:18AM -0400, Celejar wrote:
Alternatively, for internal-only stuff, you can use ULAs. IPv6
The context of our discussion is seamless and collision-free host access
across a VPN, not "internal-only stuff" - unless your directions below
are going to work even when the
On Thu, 18 Apr 2019 10:10:38 -0400
Michael Stone wrote:
> On Thu, Apr 18, 2019 at 10:00:28AM -0400, Celejar wrote:
> >Can you point me to such documenation? You've said that it's a trivial,
> >straightforward change: what, exactly, do I do to start using IPv6?
>
> Find an IPv6 provider. There's
On Thu, Apr 18, 2019 at 10:00:28AM -0400, Celejar wrote:
Can you point me to such documenation? You've said that it's a trivial,
straightforward change: what, exactly, do I do to start using IPv6?
Find an IPv6 provider. There's not much debian can document about that.
Alternatively, for intern
On Thu, 18 Apr 2019 08:50:17 -0400
Michael Stone wrote:
> On Wed, Apr 17, 2019 at 08:45:50PM -0400, Celejar wrote:
> >You make it sound like it's a trivial, straightforward change. Is it?
>
> Pretty much.
>
> >Will all my applications work correctly over IPv6 without much work?
>
> Unless you
On Thu, Apr 18, 2019 at 08:12:04AM -0500, Nicholas Geovanis wrote:
But isn't it irrelevant whether they pick the same prefix or not? Routers that
respect ULA and RFC1918 shouldn't route any traffic destined to them off the
logical subnet. Right?
If it didn't matter, people wouldn't keep looking
On Thu, Apr 18, 2019 at 7:57 AM Michael Stone wrote:
>
> No, the ULA is the IPv6 equivalent of RFC1918 space--you can use it
> internally without central registration by choosing a subnet from
> fd00::/8. The space is so much larger that it's much less likely that
> two sites would pick the same
On Wed, Apr 17, 2019 at 08:06:05PM -, Curt wrote:
On 2019-04-17, Pascal Hambourg wrote:
Le 17/04/2019 à 18:42, Michael Stone a écrit :
On Wed, Apr 17, 2019 at 12:38:11PM -0400, Celejar wrote:
On Wed, 17 Apr 2019 12:10:56 -0400 Michael Stone
wrote:
On Wed, Apr 17, 2019 at 11:57:43AM -04
On Wed, Apr 17, 2019 at 09:37:36PM +0200, Pascal Hambourg wrote:
Le 17/04/2019 à 18:42, Michael Stone a écrit :
On Wed, Apr 17, 2019 at 12:38:11PM -0400, Celejar wrote:
On Wed, 17 Apr 2019 12:10:56 -0400 Michael Stone
wrote:
On Wed, Apr 17, 2019 at 11:57:43AM -0400, Celejar wrote:
I was ra
On Wed, Apr 17, 2019 at 08:45:50PM -0400, Celejar wrote:
You make it sound like it's a trivial, straightforward change. Is it?
Pretty much.
Will all my applications work correctly over IPv6 without much work?
Unless you've written something yourself (badly) IPv6 has "just worked"
in debian
On Wed, 17 Apr 2019 18:41:46 -0400
Michael Stone wrote:
> On Wed, Apr 17, 2019 at 06:11:43PM -0400, Celejar wrote:
> >In other words, with IPv4, there's no *practical* solution, since a
> >typical end user isn't going to get arbitrary numbers of IP addresses.
>
>
On Wed, Apr 17, 2019 at 06:11:43PM -0400, Celejar wrote:
In other words, with IPv4, there's no *practical* solution, since a
typical end user isn't going to get arbitrary numbers of IP addresses.
So use IPv6.
ferring to IPv6? I was referring to IPv4.
>
> It applies to both, though we've run out of IPv4. There's no other way
In other words, with IPv4, there's no *practical* solution, since a
typical end user isn't going to get arbitrary numbers of IP addresses.
> to guarantee the absence of network collisions.
Celejar
On 2019-04-17, Pascal Hambourg wrote:
> Le 17/04/2019 à 18:42, Michael Stone a écrit :
>> On Wed, Apr 17, 2019 at 12:38:11PM -0400, Celejar wrote:
>>> On Wed, 17 Apr 2019 12:10:56 -0400 Michael Stone
>>> wrote:
>>>
On Wed, Apr 17, 2019 at 11:57:43AM -0400, Celejar wrote:
>I was rather
Le 17/04/2019 à 18:42, Michael Stone a écrit :
On Wed, Apr 17, 2019 at 12:38:11PM -0400, Celejar wrote:
On Wed, 17 Apr 2019 12:10:56 -0400 Michael Stone
wrote:
On Wed, Apr 17, 2019 at 11:57:43AM -0400, Celejar wrote:
>I was rather shocked to see that there was no definitive solution to
>avoi
On Thu, 18 Apr 2019 04:49:56 +1200
Richard Hector wrote:
> On 18/04/19 12:15 AM, Celejar wrote:
> > Currently, my LAN is 192.168.0.0/24, which is also the addressing
> > scheme of some of the networks out of my control that I'm setting up a
> > VPN link from. I deliberately used 10.0.0.0/24 for t
On 18/04/19 12:15 AM, Celejar wrote:
> Currently, my LAN is 192.168.0.0/24, which is also the addressing
> scheme of some of the networks out of my control that I'm setting up a
> VPN link from. I deliberately used 10.0.0.0/24 for the VPN to avoid
> address collisions with these other networks. It
On Wed, Apr 17, 2019 at 12:38:11PM -0400, Celejar wrote:
On Wed, 17 Apr 2019 12:10:56 -0400 Michael Stone wrote:
On Wed, Apr 17, 2019 at 11:57:43AM -0400, Celejar wrote:
>Thanks. When I first set up the VPN, I did some reading about this, and
>I was rather shocked to see that there was no defi
On Wed, 17 Apr 2019 12:10:56 -0400
Michael Stone wrote:
> On Wed, Apr 17, 2019 at 11:57:43AM -0400, Celejar wrote:
> >Thanks. When I first set up the VPN, I did some reading about this, and
> >I was rather shocked to see that there was no definitive solution to
> >avoid address collisions
>
> Su
On Wed, Apr 17, 2019 at 11:57:43AM -0400, Celejar wrote:
Thanks. When I first set up the VPN, I did some reading about this, and
I was rather shocked to see that there was no definitive solution to
avoid address collisions
Sure there is--globally unique IPs.
On Wed, 17 Apr 2019 14:59:53 +0100
Joe wrote:
> On Wed, 17 Apr 2019 08:15:09 -0400
> Celejar wrote:
>
>
> > Currently, my LAN is 192.168.0.0/24, which is also the addressing
> > scheme of some of the networks out of my control that I'm setting up a
> > VPN link from. I deliberately used 10.0.0
On Wed, 17 Apr 2019 15:29:50 +0200
Kevin DAGNEAUX wrote:
>
> Le 17/04/2019 à 14:15, Celejar a écrit :
> > On Wed, 17 Apr 2019 08:37:20 +0200
> > Kevin DAGNEAUX wrote:
> >
> >>> Hi,
> >>>
> >>> I've been bedeviled by this question for a while, but have been unable
> >>> to figure out a clean, no
On Wed, 17 Apr 2019 08:15:09 -0400
Celejar wrote:
> Currently, my LAN is 192.168.0.0/24, which is also the addressing
> scheme of some of the networks out of my control that I'm setting up a
> VPN link from. I deliberately used 10.0.0.0/24 for the VPN to avoid
> address collisions with these oth
Le 17/04/2019 à 14:15, Celejar a écrit :
On Wed, 17 Apr 2019 08:37:20 +0200
Kevin DAGNEAUX wrote:
Hi,
I've been bedeviled by this question for a while, but have been unable
to figure out a clean, non-hackish solution. It may be an XY problem ...
I have a system (laptop, running Debian) that
On Wed, 17 Apr 2019 08:37:20 +0200
Kevin DAGNEAUX wrote:
>
> > Hi,
> >
> > I've been bedeviled by this question for a while, but have been unable
> > to figure out a clean, non-hackish solution. It may be an XY problem ...
> >
> > I have a system (laptop, running Debian) that is sometimes connec
Hi,
I've been bedeviled by this question for a while, but have been unable
to figure out a clean, non-hackish solution. It may be an XY problem ...
I have a system (laptop, running Debian) that is sometimes connected
directly to my LAN, and sometimes connected via VPN (wireguard, to the
local
On Wed, 17 Apr 2019 13:45:05 +1200
Richard Hector wrote:
> On 17/04/19 3:03 AM, Celejar wrote:
...
> > What I seem to want (but maybe XY?) is some way to adjust the host
> > files (or dnsmasq's information) so that the hostname will resolve to
> > the LAN address when the laptop is connected to
On 17/04/19 3:03 AM, Celejar wrote:
> Hi,
>
> I've been bedeviled by this question for a while, but have been unable
> to figure out a clean, non-hackish solution. It may be an XY problem ...
>
> I have a system (laptop, running Debian) that is sometimes connected
> directly to my LAN, and someti
On Tue, 16 Apr 2019 20:45:54 +0200
Pascal Hambourg wrote:
> Le 16/04/2019 à 17:03, Celejar a écrit :
> >
> > What I seem to want (but maybe XY?) is some way to adjust the host
> > files (or dnsmasq's information) so that the hostname will resolve to
> > the LAN address when the laptop is connect
Le 16/04/2019 à 17:03, Celejar a écrit :
What I seem to want (but maybe XY?) is some way to adjust the host
files (or dnsmasq's information) so that the hostname will resolve to
the LAN address when the laptop is connected to the LAN, and the VPN
address when it's connected via VPN. [...]
What i
Hi,
I've been bedeviled by this question for a while, but have been unable
to figure out a clean, non-hackish solution. It may be an XY problem ...
I have a system (laptop, running Debian) that is sometimes connected
directly to my LAN, and sometimes connected via VPN (wireguard, to the
local rou
On Fri, Sep 01, 2017 at 12:28:05PM -0400, Thomas George wrote:
> I have tried ping 192.168.1.225 followed by arp -a
>
> and I have tried netstat -r
>
> Neither report ip addresses of attached devices.
>
> I know there are two devices besides this pc and I know the addr
Thomas George, Fr 01 Sep 2017 18:28:05 CEST:
> I have tried ping 192.168.1.225 followed by arp -a
Really .225 and not .255? If so, why?
> and I have tried netstat -r
>
> Neither report ip addresses of attached devices.
>
> I know there are two devices besides this pc and I k
I have tried ping 192.168.1.225 followed by arp -a
and I have tried netstat -r
Neither report ip addresses of attached devices.
I know there are two devices besides this pc and I know the address of
one of these devices. I can ping it and it responds.
How to find the address of the second
Hi,
i wrote:
> > mknod ~/fifo p
> > netcat -u PORT1 <~/fifo
> > data_producer | tee -i ~/fifo | netcat -u PORT2
Paul Duncan wrote:
> I shall give that a go
I forgot to mention that i ran my test mockup of the last two commands
concurrently in two shell terminals. (The fi
Hi,
Paul Duncan wrote:
> what the best way is to send it to two IP addresses?
If it must happen without much time to study the web, i'd use tee(1)
to feed a named pipe from the unnamed one. Then netcat can consume both.
mknod ~/fifo p
netcat -u PORT1 <~/fifo
data_producer | te
o two
IP addresses?
Just as an aside the program reads data from a serial port, so I cannot
simply run a second instance of the program.
Thanks!
Paul.
On Sat, 10 Sep 2016, Joe wrote:
> > - From your question I'm not sure this is the answer you are looking
> > for, but I'll give it a try. According to RFC 1918 [1], the following
> > address ranges are reserved for "private use":
> >
> > 10.0.0.0- 10.255.255.255 (10/8 prefix)
> >
On Sat, 10 Sep 2016 19:58:50 +0200
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Sat, Sep 10, 2016 at 07:36:11PM +0200, Andre Majorel wrote:
> > Is there a tool which would take IPv4 addresses on the command
> > line and say whether or not they are regular and routable ?
> >
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, Sep 10, 2016 at 07:36:11PM +0200, Andre Majorel wrote:
> Is there a tool which would take IPv4 addresses on the command
> line and say whether or not they are regular and routable ?
>
> host(1) is not very useful for that as it doesn't seem to
Is there a tool which would take IPv4 addresses on the command
line and say whether or not they are regular and routable ?
host(1) is not very useful for that as it doesn't seem to
distinguish between an address which happens not to used by a
domain name at this time (eg 9.9.9.9) and one which cou
On Friday 31 October 2014 08:45:41 Karl E. Jorgensen wrote:
> There is nothing wrong with configuring a server with a fixed IP
> address (=not use DHCP client), as long as you use the correct
> network, netmask and default gateway.
This would appear to me to be the obvious solution. Is there a pr
x27;t allow me to specify
fix IPs in the internal network for all of our machines.
Well - even if it doesn't, surely it allows you to specify which
*range* of IP addresses should be used for DHCP?
There is nothing wrong with configuring a server with a fixed IP
address (=not use DHCP client),
> fix IPs in the internal network for all of our machines.
> >
> > Well - even if it doesn't, surely it allows you to specify which
> > *range* of IP addresses should be used for DHCP?
> >
> > There is nothing wrong with configuring a server with a fixed IP
>
e telephone and
>> internet over the cable network and the company gives us a wlan
>> modem for free. Unfortunately this modem doesn't allow me to specify
>> fix IPs in the internal network for all of our machines.
>
> Well - even if it doesn't, surely it a
fix IPs in the internal network for all of our machines.
Well - even if it doesn't, surely it allows you to specify which
*range* of IP addresses should be used for DHCP?
There is nothing wrong with configuring a server with a fixed IP
address (=not use DHCP client), as long as you use the
cloud server on one machine (which is somehow our
"server" but not always running), including SSL encryption with a self-signed
certificate for its IP address. That worked well for a couple of months because
the IP addresses didn't change (although they were not fixed).
Now due to
Chris Davies wrote:
> Bonno Bloksma wrote:
> > I routinely add or remove ip addresses from an interface without having
> > to bring the physical interface up or down.
>
> Me too. (Well, not routinely, but quite comfortably. It's very convenient
> when needing to talk
Bonno Bloksma wrote:
> I routinely add or remove ip addresses from an interface without having
> to bring the physical interface up or down.
Me too. (Well, not routinely, but quite comfortably. It's very convenient
when needing to talk to a new device that's got a default init
On Tue, Oct 22, 2013 at 12:28 PM, Bonno Bloksma wrote:
>
> allow-auto eth0.9
> iface eth0.9 inet static
> address 192.168.1.119
> netmask 255.255.255.0
> gateway 192.168.1.1
> post-up ip address add 192.168.1.199/24 dev eth0.9
>>>
>>> What I use is:
>>> -=-=-=-=
can be handled independent of the
physical status of the interface but still react with the interface when it
comes up or goes down. See my other mail with this subject.
I routinely add or remove ip addresses from an interface without having to
bring the physical interface
Hi,
allow-auto eth0.9
iface eth0.9 inet static
address 192.168.1.119
netmask 255.255.255.0
gateway 192.168.1.1
post-up ip address add 192.168.1.199/24 dev eth0.9
>>
>> What I use is:
>> -=-=-=-=-=-
>> auto eth0
>> iface eth0 inet static
>> address 172.
Bob Proulx wrote:
> Tom H wrote:
>> I'm pretty sure that the last time (six months ago?) Bob linked to a
>> Debian wiki page [...] that used multiple iface declarations for the
>> same nic (I've also used multiple declarations).
>
> https://wiki.debian.org/NetworkConfiguration#Multiple_IP_addre
On Mon, Oct 21, 2013 at 7:29 AM, Bonno Bloksma wrote:
>>>
>>> allow-auto eth0.9
>>> iface eth0.9 inet static
>>> address 192.168.1.119
>>> netmask 255.255.255.0
>>> gateway 192.168.1.1
>>> post-up ip address add 192.168.1.199/24 dev eth0.9
>
> What I use is:
> -=-=-=-=-=-
> auto eth0
> ifa
Hi Steffen,
>> allow-auto eth0.9
>> iface eth0.9 inet static
>> address 192.168.1.119
>> netmask 255.255.255.0
>> gateway 192.168.1.1
>> post-up ip address add 192.168.1.199/24 dev eth0.9
What I use is:
-=-=-=-=-=-
auto eth0
iface eth0 inet static
address 172.16.17.1
netma
On Fri, Oct 18, 2013 at 4:11 PM, Steffen Dettmer
wrote:
> On Fri, Oct 18, 2013 at 3:24 PM, Tom H wrote:
>>> allow-auto eth0.9
>>> iface eth0.9 inet static
>>> address 192.168.1.119
>>> netmask 255.255.255.0
>>> gateway 192.168.1.1
>>> post-up ip address add 192.168.1.199/24 dev eth0.9
>
On Fri, Oct 18, 2013 at 4:03 PM, Steffen Dettmer
wrote:
> On Fri, Oct 18, 2013 at 3:24 PM, Tom H wrote:
>>> I'm using Wheezy with ifup version 0.7.8, I think this is the
>>> latest officially released (aka "the best") one?
>>
>> Strange. I was under the impression that Debian 7's ifupdown is us
Tom H wrote:
> Chris Davies wrote:
> > Tom H wrote:
> >> iface eth3.77 inet static
> >> address 10.0.5.15
> >
> >> iface eth3.77 inet static
> >> address 10.0.5.16
> >
> > The Debian documentation at
> > http://www.debian.org/doc/manuals/debian-reference/ch05.en.html states
> > categorically, « Do
distract from the discussion between you and Tom I am
going to refrain from saying more about that here and now.
> > Configuring multiple IP addresses on interfaces like that is new in
> > recent versions of ifupdown.
>
> Wow, this is surprising! I considered it an old basic classi
Miles Fidelman wrote:
> for what it's worth, my (working, for years) /etc/network/interfaces
> file looks like this:
In addition to what Tom said, you have redundant network and broadcast
statements. If you specify the netmask then the network and broadcast
will be calculated from the netmask.
B
Tom H wrote:
> Bob Proulx wrote:
> > Of course I know nothing about vlan configuration so I am likely wrong
> > here. I just know that visually it doesn't match. However all of the
> > docs I see just now suggest using a bridge. Perhaps something like this.
> >
> > auto eth0
> > allow-hotplu
On Fri, Oct 18, 2013 at 3:24 PM, Tom H wrote:
>> --->8===
>> auto lo
>> iface lo inet loopback
>>
>> allow-auto eth0.9
>> iface eth0.9 inet static
>> address 192.168.1.119
>> netmask 255.255.255.0
>> gateway 192.168.1.1
>>
Hi!
On Fri, Oct 18, 2013 at 3:24 PM, Tom H wrote:
>> I'm using Wheezy with ifup version 0.7.8, I think this is the
>> latest officially released (aka "the best") one?
>
> Strange. I was under the impression that Debian 7's ifupdown is using
> iproute but you had a vconfig error in an earlier emai
e physical interface).
The OP's asking about eth0.1 NOT eth0:1.
They're both virtual. The first is an interface whose broadcast domain
is defined and limited by the "1" and the second is an alias that
allows you to assign extra ip addresses to an interface. The alias
con
Tom H wrote:
On Fri, Oct 18, 2013 at 12:35 PM, Miles Fidelman
wrote:
Steffen Dettmer wrote:
I'd like to configure multiple IP addresses to a VLAN tagged interface. I
tried
auto eth3.107
iface eth3.77 inet static
address 10.0.5.15
netmask 255.255.255.0
iface eth3.77
On Fri, Oct 18, 2013 at 12:35 PM, Miles Fidelman
wrote:
> Steffen Dettmer wrote:
>>
>> I'd like to configure multiple IP addresses to a VLAN tagged interface. I
>> tried
>>
>> auto eth3.107
>>iface eth3.77 inet static
>>address 10.0.5.
On Fri, Oct 18, 2013 at 11:36 AM, Chris Davies wrote:
> Tom H wrote:
>> iface eth3.77 inet static
>> address 10.0.5.15
>
>> iface eth3.77 inet static
>> address 10.0.5.16
>
> The Debian documentation at
> http://www.debian.org/doc/manuals/debian-reference/ch05.en.html states
> categorically, « Do
On Fri, Oct 18, 2013 at 12:05 PM, Steffen Dettmer
wrote:
> On Fri, Oct 18, 2013 at 1:18 PM, Tom H wrote:
> thanks again for your fast help.
You're welcome.
>> So Bob must be right about your ifupdown version not using iproute
>
> I'm using Wheezy with ifup version 0.7.8, I think this is the
Hi,
just in case someone still reading my boring DHCP client attempts, to
complete the topic here my findings about behavior at shutdown. Even
with simply /etc/network/interfaces configuration:
allow-hotplug eth3.77
iface eth3.77 inet dhcp
and manually starting "ifup eth3.77" after boot, on
Steffen Dettmer wrote:
Hi,
I'd like to configure multiple IP addresses to a VLAN tagged interface. I tried
auto eth3.107
iface eth3.77 inet static
address 10.0.5.15
netmask 255.255.255.0
iface eth3.77 inet static
address 10.0.5.16
netmask 255.255.255.0
but I get an
Tom H wrote:
> iface eth3.77 inet static
> address 10.0.5.15
> iface eth3.77 inet static
> address 10.0.5.16
The Debian documentation at
http://www.debian.org/doc/manuals/debian-reference/ch05.en.html states
categorically, « Do not define duplicates of the "iface" stanza for a
network interface
1 - 100 of 279 matches
Mail list logo
