similar to: PXE over HTTP instead of TFTP - flip flopping OS boots

On Tue, Feb 14, 2017 at 11:21:34AM -0500, James Hartig wrote: > Those 2 boxes are in the same subnet and have addresses of 10.240.0.4 and > 10.240.0.5, respectively, on their eth0 interface. Port 655 on tcp and udp > is open to the world. The tinc_test_2 box has a ConnectTo of tinc_test_1. > When tinc_test_2 is started, it prints out: > UDP address of tinc_test_1 set to

On 14 February 2017 at 18:59, James Hartig <james at levenlabs.com> wrote: > When you say "and to the local network" what IP does it try to send to > on the local network? The subnet address? No. The Subnet option deals with routing *inside* the VPN, not the underlying "real" network. In tinc 1.1, the address that local discovery probes are sent to is the local

On Tue, Feb 14, 2017 at 1:22 PM, Etienne Dechamps <etienne at edechamps.fr> wrote: > > Can you specify which version of tinc you're using? There are vast differences in the way LocalDiscovery works between 1.0 and 1.1. The former uses broadcast, the latter unicast to explicitly advertised local addresses. I'm using tinc 1.1pre14. I noticed there's an option,

Can you specify which version of tinc you're using? There are vast differences in the way LocalDiscovery works between 1.0 and 1.1. The former uses broadcast, the latter unicast to explicitly advertised local addresses. You say that tinc_test_1's eth0 interface is configured with 10.240.0.4, and tinc_test_2's eth0 interface is configured with 10.240.0.5. How are the public addresses

On Tue, Feb 14, 2017 at 3:43 PM, Etienne Dechamps <etienne at edechamps.fr> wrote: > Hang on a second. I've just re-read your original message and I > believe you are confused about what the "Subnet" option does. Again, > it deals with addresses *inside* the VPN. In the configuration you > posted you seem to be using 10.240.0.4 and 10.240.0.5 as internal >

On Tue, Feb 14, 2017 at 1:46 PM, Guus Sliepen <guus at tinc-vpn.org> wrote: > On Tue, Feb 14, 2017 at 11:21:34AM -0500, James Hartig wrote: > >> Those 2 boxes are in the same subnet and have addresses of 10.240.0.4 and >> 10.240.0.5, respectively, on their eth0 interface. Port 655 on tcp and udp >> is open to the world. The tinc_test_2 box has a ConnectTo of

These two networks can be the same, i.e. the VPN can be an extension of your local network, sharing the same subnet. That's one the many ways things can be set up. The same result can be achieved through other ways (e.g. Ethernet-level bridging). This does not contradict my earlier statement: a subnet can be *both* inside *and* outside the VPN, depending on the scenario. The Subnet

We are testing tinc inside Google Compute within a single region and an external region. Two boxes are created as follows: /etc/tinc/test/tinc_test_1 Subnet = 10.240.0.0/16 Subnet = 10.240.0.4/32 Address = 104.154.59.151 /etc/tinc/test/tinc_test_2 Subnet = 10.240.0.0/16 Subnet = 10.240.0.5/32 Address = 104.197.132.141 /etc/tinc/test/tinc.conf Name = $HOST AddressFamily = ipv4 Interface = tun0

Hang on a second. I've just re-read your original message and I believe you are confused about what the "Subnet" option does. Again, it deals with addresses *inside* the VPN. In the configuration you posted you seem to be using 10.240.0.4 and 10.240.0.5 as internal addresses, but then your other statements (and especially your dump edges output) seem to indicate that 10.240.0.4 and

@Etienne, I understood your explanation about the Subnet being the network *inside* the VPN, but the following the example https://www.tinc-vpn.org/examples/proxy-arp/, it seems to have: Subnet = 192.168.1.0/24 for the office, yet the IP address for the office is 192.168.1.2. Is that example no longer valid or am I misunderstanding? On Tue, Feb 14, 2017 at 4:01 PM, James Hartig <james at

> Im a long time PXE boot fan. I use it for wimbooting windows PE, linux > images via http, and memtest mainly. > > Ive got it nicely customised with my own graphics etc. > > Then UEFI booting came along. Till now ive been content simply setting > bios's to CSM mode and doing my thing.... > > Ive had another go at EFI PXE booting and can now get the menus and

Im a long time PXE boot fan. I use it for wimbooting windows PE, linux images via http, and memtest mainly. Ive got it nicely customised with my own graphics etc. Then UEFI booting came along. Till now ive been content simply setting bios's to CSM mode and doing my thing.... Ive had another go at EFI PXE booting and can now get the menus and grahics from syslinux working, but I cannot get

Hello, I'm playing with gpxelinux, it's works but ... In my dhcpd.conf I have the traditional: option space gpxelinux; option gpxelinux-encap-opts code 175 = encapsulate gpxelinux; option gpxelinux.bus-id code 177 = string; subnet 192.168.0.0 netmask 255.255.255.0 { host essai { hardware ethernet 00:11:22:33:44:55; fixed-address 192.168.0.62; if not exist

Hi guys! I tried to boot memtest86+ v4.2 (renamed memtest.bin to memtest), and i have issues to boot it with pxelinux 5.x and greater.Pxelinux 4.06 works fine both memtest 4.1 and 4.2. With version 6.00 no error message caught, only writes out dots. Any keypress does a reboot.With version 5.01 the error message is the follow:Loading images/memtest/memtest86... okBooting kernel failed: Bad file

Hello, FYI. This problem looks similar to the problem I reported in Februari http://www.syslinux.org/archives/2013-February/019517.html Kind regards, Wim. On 06/28/2013 10:02 AM, Matt Fleming wrote: > On Fri, 28 Jun, at 08:13:03AM, N?meth P?ter wrote: >> Hi guys! >> I tried to boot memtest86+ v4.2 (renamed memtest.bin to memtest), and >> i have issues to boot it with

Hello, I'm trying to pass the serial port options to memtest86+ using Syslinux 5.01 but is not working. Debugging the memtest86+, the check at main.cpp function static void parse_command_line(void) if (*OLD_CL_MAGIC_ADDR != OLD_CL_MAGIC) return; Is being evaluated to true. What should I do? There is a way to instruct memtest to use the "old way" to pass

Hello list, any try the new memtest86 v3.2 with isolinux 3.11 cd and pxeboot? How is the proper way to chainload memtest86 I was tried: label memtest kernel memtest.bin but, nothing happens just a weird hang (my older versions of memtest hangs too). Anyway chainloading in a floppy image with memdisk on CD or pxeboot was fine but if I use memory to emulate a floppy I was not using this memory

Hi there, ----- Original Message ----- From: koxudaxi at gmail.com To: syslinux at zytor.com Date: 01.04.2013 10:00:27 Subject: Re: [syslinux] Problem with pxelinux 5.0 and memtest > On 04/01/2013 09:28 AM, H. Peter Anvin wrote: >> On 03/31/2013 05:26 PM, Koudai Aono wrote: >>> I ran the test on a x86 emulator is called Oracle VirtualBox. >>> I think it might not be

Hello, This is my first post to this list. After searching through the archives and google searches I could not find a solution for my memtest problem. In previous versions of pxelinux/gpxelinux (4.04 and 4.06) I could successfully start the memtest utility. But using pxelinux/gpxelinux versions 5.01 and 5.02 the memtest utility does not boot and I get an error message: boot: Loading

Additional information: I was tried it with 2 virtualbox (version 4.2.14r86644).1rst: debian weezy with isc-dhcp-server, pxelinux5.01, pxelinux 6.00, tftp-hpa2nd: empty virtualbox booting from virtual network card. So memtest 4.1 and 4.2 worked with pxelinux 4.06 Peter > Date: Fri, 28 Jun 2013 09:02:30 +0100 > From: matt at console-pimps.org > To: coolpet80 at hotmail.com > CC: