leaf-user — This mailing list is for all users and developers of LEAF.

Re: [leaf-user] 7.5.x cannot boots - EFI problem?

[Graziano B. <gra...@ou...>]

Thank you Robert for your tests

I will try to reinstall my system on wedsday and i'll make some other 
test on it; then, i'll also try to install LEAF 7.5.1-beta1 on a ESXi VM 
machine configured with EFI firmware to check if my installation 
procedure is correct.

thanks a  lot

Graziano


Il 21/07/2025 16:16, Robert K Coffman Jr. -Info From Data Corp. ha scritto:
>     I copied my image to a USB drive, updated it to 7.5.1-beta and after
>     fixing the leaf.cfg file that I accidentally overwrote, I successfully
>     UEFI booted 7.5.1-beta.
>
>     USB is broken - at least with the keyboards and KVM I have here, even
>     in single user mode.  But the system is booted.  This is a PC set to
>     only boot UEFI.  I have secure boot disabled.  I didn't dig too deeply
>     but I didn't even see secure boot as an option on this thing.
>
>     HTH -
>
>     Bob
>
>     On 7/21/2025 4:38:06 AM, Graziano Brioschi wrote:
>
>       Hi list,
>       I'm tring to install the new LEAF 7.5.1-beta1 X86_64 without success
>       on a SBC that have a UEFI firmware that does not support "Legacy
>       BIOS" or "CSM mode" (/Compatibility Support Module/). After POST, I
>       can see the LEAF logo and nothing more
>       On the same hardware LEAF 7.3.1.1 x86_64 version boots correctly.
>       Is there someone that can confirm that the x86_64 kernel included on
>       new 7.5.x version supports EFI?
>       Thanks
>       Graziano
>
> --
> Robert K Coffman Jr.
> Info From Data Corp.
> 3307249000
> [1]su...@in...
>
> References
>
>     1. mailto:su...@in...
>
> ------------------------------------------------------------------------
> leaf-user mailing list: lea...@li...
> https://lists.sourceforge.net/lists/listinfo/leaf-user
> Support Request -- http://leaf-project.org/

-- 

Graziano Brioschi

Outland s.a.s.
sede operativa:
Via A. Don Rocca, 13
20030, Senago (MI)
tel: 02 9948 6014
mobile: 328 8382622
email: gra...@ou...
--> U4E <--

Re: [leaf-user] 7.5.x cannot boots - EFI problem?

[Robert K C. J. -I. F. D. Corp. <bco...@in...>]

   I copied my image to a USB drive, updated it to 7.5.1-beta and after
   fixing the leaf.cfg file that I accidentally overwrote, I successfully
   UEFI booted 7.5.1-beta.

   USB is broken - at least with the keyboards and KVM I have here, even
   in single user mode.  But the system is booted.  This is a PC set to
   only boot UEFI.  I have secure boot disabled.  I didn't dig too deeply
   but I didn't even see secure boot as an option on this thing.

   HTH -

   Bob

   On 7/21/2025 4:38:06 AM, Graziano Brioschi wrote:

     Hi list,
     I'm tring to install the new LEAF 7.5.1-beta1 X86_64 without success
     on a SBC that have a UEFI firmware that does not support "Legacy
     BIOS" or "CSM mode" (/Compatibility Support Module/). After POST, I
     can see the LEAF logo and nothing more
     On the same hardware LEAF 7.3.1.1 x86_64 version boots correctly.
     Is there someone that can confirm that the x86_64 kernel included on
     new 7.5.x version supports EFI?
     Thanks
     Graziano

--
Robert K Coffman Jr.
Info From Data Corp.
3307249000
[1]su...@in...

References

   1. mailto:su...@in...

[leaf-user] 7.5.x cannot boots - EFI problem?

[Graziano B. <gra...@ou...>]

Hi list,

I'm tring to install the new LEAF 7.5.1-beta1 X86_64 without success on 
a SBC that have a UEFI firmware that does not support "Legacy BIOS" or 
"CSM mode" (/Compatibility Support Module/). After POST, I can see the 
LEAF logo and nothing more

On the same hardware LEAF 7.3.1.1 x86_64 version boots correctly.

Is there someone that can confirm that the x86_64 kernel included on new 
7.5.x version supports EFI?

Thanks

Graziano



-- 

Graziano Brioschi

Outland s.a.s.
sede operativa:
Via A. Don Rocca, 13
20030, Senago (MI)
tel: 02 9948 6014
mobile: 328 8382622
email:gra...@ou...
--> U4E <--

Re: [leaf-user] 7.5.0 cannot boots

[Graziano B. <gra...@ou...>]

hi,

thanks for your suggestion; I can confirm that the storage is correctly 
detected and the boot flag is set

G.

Il 13/06/2025 18:14, "Northe, Jürgen [ tux-net ]" ha scritto:
> Hi
> I would suggest to boot RescueCD live operating system with USB key to 
> see if the storage is deteced correctly and if the boot flag is set.
> Both can be achieved with gparted
>
> Download <https://www.system-rescue.org/Download/>
> system-rescue.org <https://www.system-rescue.org/Download/>
> 	favicon.ico <https://www.system-rescue.org/Download/>
>
> <https://www.system-rescue.org/Download/>
>
>
> J. Northe
>
>> Am 13.06.2025 um 16:29 schrieb Graziano Brioschi 
>> <gra...@ou...>:
>>
>> Hi list,
>>
>> I have tried to install leaf 7.5.0 x86_64 - VGA console - on an 
>> industrial PC without success; after the POST, nothing appears on VGA 
>> console and it reboot after few seconds.
>>
>> This machine is based on a SBC with CPU Intel Atom E3825, 4 Gigabit 
>> Intel I211 and with  firmware configured to boot in "UEFI and Legacy" 
>> mode. (Firmware BIOS UEFI v2.40 PI 1.3 by American Megatrends)
>>
>> On first try, I have installed it in "legacy mode" (single MBR 
>> partition, syslinux installed on MBR), but the system does not boot 
>> correcty (it reboots after few seconds)
>>
>> As second chance, I have installed it in "UEFI" mode (sigle 
>> partition, UEFI configured on storage) but it do not start as well 
>> (it always reboot after some seconds).
>>
>> The same system boots correctly using a 7.3.1 version (in "legacy 
>> mode" and in "UEFI" mode as well).
>>
>> Are there some problems in new 7.5.0 version and UEFI systems? is the 
>> new kernel version enabled to support EFI?
>>
>> Thanks in advance
>>
>> Ciao
>>
>> Graziano
>>
>> -- 
>>
>> Graziano Brioschi
>>
>> Outland s.a.s.
>> sede operativa:
>> Via A. Don Rocca, 13
>> 20030, Senago (MI)
>> tel: 02 9948 6014
>> mobile: 328 8382622
>> email: gra...@ou...
>> --> U4E <--
>>
>>
>>
>> ------------------------------------------------------------------------
>> leaf-user mailing list: lea...@li...
>> https://lists.sourceforge.net/lists/listinfo/leaf-user
>> Support Request -- http://leaf-project.org/

-- 

Graziano Brioschi

Outland s.a.s.
sede operativa:
Via A. Don Rocca, 13
20030, Senago (MI)
tel: 02 9948 6014
mobile: 328 8382622
email:gra...@ou...
--> U4E <--

Re: [leaf-user] 7.5.0 cannot boots

[Graziano B. <gra...@ou...>]

Hi Marko,

I can confirm that the boot media (an 120GB SSD disk) have an MBR; for 
the installation process, I have booted with PC using a USB key with 
uCLibc 7.3.1 system and write the MBR using the following command:

  # dd bs=440 count=1 if=/usr/share/syslinux/mbr.bin of=/dev/sdX

thanks

G.

Il 14/06/2025 01:28, marko via leaf-user ha scritto:
> does the media have an MBR?
>
>
> sudo dd bs=440 if=/usr/lib/syslinux/mbr/mbr.bin of=/dev/sdx
>
>
>
> On Saturday, 14 June 2025 12:11:45 AM AEST Graziano Brioschi wrote:
>> Hi list,
>>
>> I have tried to install leaf 7.5.0 x86_64 - VGA console - on an
>> industrial PC without success; after the POST, nothing appears on VGA
>> console and it reboot after few seconds.
>>
>> This machine is based on a SBC with CPU Intel Atom E3825, 4 Gigabit
>> Intel I211 and with  firmware configured to boot in "UEFI and Legacy"
>> mode. (Firmware BIOS UEFI v2.40 PI 1.3 by American Megatrends)
>>
>> On first try, I have installed it in "legacy mode" (single MBR
>> partition, syslinux installed on MBR), but the system does not boot
>> correcty (it reboots after few seconds)
>>
>> As second chance, I have installed it in "UEFI" mode (sigle partition,
>> UEFI configured on storage) but it do not start as well (it always
>> reboot after some seconds).
>>
>> The same system boots correctly using a 7.3.1 version (in "legacy mode"
>> and in "UEFI" mode as well).
>>
>> Are there some problems in new 7.5.0 version and UEFI systems? is the
>> new kernel version enabled to support EFI?
>>
>> Thanks in advance
>>
>> Ciao
>>
>> Graziano
>
>
>
>
> ------------------------------------------------------------------------
> leaf-user mailing list: lea...@li...
> https://lists.sourceforge.net/lists/listinfo/leaf-user
> Support Request -- http://leaf-project.org/

-- 

Graziano Brioschi

Outland s.a.s.
sede operativa:
Via A. Don Rocca, 13
20030, Senago (MI)
tel: 02 9948 6014
mobile: 328 8382622
email: gra...@ou...
--> U4E <--

Re: [leaf-user] ulogd not running

[KP.Kirchdoerfer <ka...@be...>]

Am Donnerstag, 22. Mai 2025, 20:03:42 Mitteleuropäische Sommerzeit schrieb Jim 
Munro:
> Hi all,
> 
> Just did a fresh install of 7.5.0 and ulogd is not running and wont start.
> 
> from ulogd.log:
> 
> Thu May 22 17:41:39 2025 <7> ulogd.c:720 load_plugin:
> '/usr/lib/ulogd/ulogd_inppkt_NFLOG.so': (null) Thu May 22 17:41:39 2025 <7>
> ulogd.c:1006 can't find requested plugin NFLOG Thu May 22 17:41:39 2025 <7>
> ulogd.c:1006 can't find requested plugin NFLOG Thu May 22 17:41:39 2025 <8>
> ulogd.c:1595 not even a single working plugin stack
> 
> Have I missed something?  Or is something broken?  I'm using the default
> leaf.cfg and configdb.lrp

It was broken.

Fix committed to git incl. update to ulogd 2.0.9

kp

Re: [leaf-user] 7.5.0 cannot boots

[marko <le...@me...>]

does the media have an MBR?  


sudo dd bs=440 if=/usr/lib/syslinux/mbr/mbr.bin of=/dev/sdx



On Saturday, 14 June 2025 12:11:45 AM AEST Graziano Brioschi wrote:
> Hi list,
> 
> I have tried to install leaf 7.5.0 x86_64 - VGA console - on an
> industrial PC without success; after the POST, nothing appears on VGA
> console and it reboot after few seconds.
> 
> This machine is based on a SBC with CPU Intel Atom E3825, 4 Gigabit
> Intel I211 and with  firmware configured to boot in "UEFI and Legacy"
> mode. (Firmware BIOS UEFI v2.40 PI 1.3 by American Megatrends)
> 
> On first try, I have installed it in "legacy mode" (single MBR
> partition, syslinux installed on MBR), but the system does not boot
> correcty (it reboots after few seconds)
> 
> As second chance, I have installed it in "UEFI" mode (sigle partition,
> UEFI configured on storage) but it do not start as well (it always
> reboot after some seconds).
> 
> The same system boots correctly using a 7.3.1 version (in "legacy mode"
> and in "UEFI" mode as well).
> 
> Are there some problems in new 7.5.0 version and UEFI systems? is the
> new kernel version enabled to support EFI?
> 
> Thanks in advance
> 
> Ciao
> 
> Graziano

[leaf-user] 7.5.0 cannot boots

[Graziano B. <gra...@ou...>]

Hi list,

I have tried to install leaf 7.5.0 x86_64 - VGA console - on an 
industrial PC without success; after the POST, nothing appears on VGA 
console and it reboot after few seconds.

This machine is based on a SBC with CPU Intel Atom E3825, 4 Gigabit 
Intel I211 and with  firmware configured to boot in "UEFI and Legacy" 
mode. (Firmware BIOS UEFI v2.40 PI 1.3 by American Megatrends)

On first try, I have installed it in "legacy mode" (single MBR 
partition, syslinux installed on MBR), but the system does not boot 
correcty (it reboots after few seconds)

As second chance, I have installed it in "UEFI" mode (sigle partition, 
UEFI configured on storage) but it do not start as well (it always 
reboot after some seconds).

The same system boots correctly using a 7.3.1 version (in "legacy mode" 
and in "UEFI" mode as well).

Are there some problems in new 7.5.0 version and UEFI systems? is the 
new kernel version enabled to support EFI?

Thanks in advance

Ciao

Graziano

-- 

Graziano Brioschi

Outland s.a.s.
sede operativa:
Via A. Don Rocca, 13
20030, Senago (MI)
tel: 02 9948 6014
mobile: 328 8382622
email: gra...@ou...
--> U4E <--

[leaf-user] ulogd not running

[Jim M. <jv...@ho...>]

Hi all,

Just did a fresh install of 7.5.0 and ulogd is not running and wont start.

from ulogd.log:

Thu May 22 17:41:39 2025 <7> ulogd.c:720 load_plugin: '/usr/lib/ulogd/ulogd_inppkt_NFLOG.so': (null)
Thu May 22 17:41:39 2025 <7> ulogd.c:1006 can't find requested plugin NFLOG
Thu May 22 17:41:39 2025 <7> ulogd.c:1006 can't find requested plugin NFLOG
Thu May 22 17:41:39 2025 <8> ulogd.c:1595 not even a single working plugin stack

Have I missed something?  Or is something broken?  I'm using the default leaf.cfg and configdb.lrp

Thanks

Jim Munro

Re: [leaf-user] 7.5.0 on Alix

[Otto H. - T. <ott...@te...>]

Hi, see below...

Dne 01.05.2025 v 15:58 Erich Titl napsal(a):
> Hi
>
> Am 01.05.2025 um 15:15 schrieb KP.Kirchdoerfer:
>> Am Montag, 28. April 2025, 11:46:48 CEST schrieb Otto Halák - TeleLarm:
>>> Dear list users,
>>> Probably no one has tested versions 7.5.0 on Alix boards, because there
>>> are several problems with it.
>>>
>>> I used packages from this archive:
>>> Bering-uClibc_7.5.0_geode_syslinux_serial115200
>>>
>>> On boot I saw the following warnings:
>>> [ 36.334528] leds-gpio leds-gpio: error -ENOENT: Failed to get GPIO
>>> 'geode-leds/alix:0'
>>> [ 36.342591] leds-gpio leds-gpio: probe with driver leds-gpio failed
>>> with error -2
>
> Is this the output of modprobe?
No, this is part of boot messages showed on serial console after I 
switched the power to Alix on.
>
>>>
>>> After boot I get "firewall login:" on the serial console, but I can't
>>> log in. I can't type any letter because the console on serial port 
>>> ttyS0
>>> is dead, so I can't even create a root password.
>
> If you get the "firewall login:" prompt on the serial console then the 
> serial driver works at least partially.
When I turned on the Alix, I can see the whole boot proces on the serial 
console up to "firewall login:". Then I am unable to type any letter, 
let alone a word.
>
>>>
>>> So I replaced configdb.lrp with one created on another machine.
>>> Now I am able to log in via dropbear.
>
> Which uses the ethernet connection
Yes
>
>>>
>>> But I am not able to use the menu system lrcfg because the e3 editor is
>>> not working. Even from the command line "e3 /etc/modules" does not open
>>> the file. For all files that need to be edited, you have to use the vim
>>> editor.
>
> Obviously the e3 editor will not load. AFAIK the 3e gets loaded with 
> initrd.
>
>>
>> I confirm this  doesn't work for i486/geode/i686 and will look into it.
>>
>>>
>>> I did not test geoip on Alix, but the rest of functions and programs
>>> seems to be working fine.
>>>
>>> I'm curious if anyone can fix any of this.
>>
>> Other issues hopefully as well, but after the one above....
>
> Feels a bit like an initrd problem
>
> cheers
>
> ET
>
Cheers, Otto

Re: [leaf-user] 7.5.0 on Alix

[Erich T. <eri...@th...>]

Hi

Am 01.05.2025 um 15:15 schrieb KP.Kirchdoerfer:
> Am Montag, 28. April 2025, 11:46:48 CEST schrieb Otto Halák - TeleLarm:
>> Dear list users,
>> Probably no one has tested versions 7.5.0 on Alix boards, because there
>> are several problems with it.
>>
>> I used packages from this archive:
>> Bering-uClibc_7.5.0_geode_syslinux_serial115200
>>
>> On boot I saw the following warnings:
>> [ 36.334528] leds-gpio leds-gpio: error -ENOENT: Failed to get GPIO
>> 'geode-leds/alix:0'
>> [ 36.342591] leds-gpio leds-gpio: probe with driver leds-gpio failed
>> with error -2

Is this the output of modprobe?

>>
>> After boot I get "firewall login:" on the serial console, but I can't
>> log in. I can't type any letter because the console on serial port ttyS0
>> is dead, so I can't even create a root password.

If you get the "firewall login:" prompt on the serial console then the 
serial driver works at least partially.

>>
>> So I replaced configdb.lrp with one created on another machine.
>> Now I am able to log in via dropbear.

Which uses the ethernet connection

>>
>> But I am not able to use the menu system lrcfg because the e3 editor is
>> not working. Even from the command line "e3 /etc/modules" does not open
>> the file. For all files that need to be edited, you have to use the vim
>> editor.

Obviously the e3 editor will not load. AFAIK the 3e gets loaded with 
initrd.

> 
> I confirm this  doesn't work for i486/geode/i686 and will look into it.
> 
>>
>> I did not test geoip on Alix, but the rest of functions and programs
>> seems to be working fine.
>>
>> I'm curious if anyone can fix any of this.
> 
> Other issues hopefully as well, but after the one above....

Feels a bit like an initrd problem

cheers

ET

-- 
„Wer von seinem Tag nicht zwei Drittel für sich hat, ist ein Sklave.“
―Friedrich Nietzsche

Re: [leaf-user] 7.5.0 on Alix

[KP.Kirchdoerfer <ka...@be...>]

Am Montag, 28. April 2025, 11:46:48 CEST schrieb Otto Halák - TeleLarm:
> Dear list users,
> Probably no one has tested versions 7.5.0 on Alix boards, because there
> are several problems with it.
> 
> I used packages from this archive:
> Bering-uClibc_7.5.0_geode_syslinux_serial115200
> 
> On boot I saw the following warnings:
> [ 36.334528] leds-gpio leds-gpio: error -ENOENT: Failed to get GPIO
> 'geode-leds/alix:0'
> [ 36.342591] leds-gpio leds-gpio: probe with driver leds-gpio failed
> with error -2
> 
> After boot I get "firewall login:" on the serial console, but I can't
> log in. I can't type any letter because the console on serial port ttyS0
> is dead, so I can't even create a root password.
> 
> So I replaced configdb.lrp with one created on another machine.
> Now I am able to log in via dropbear.
> 
> But I am not able to use the menu system lrcfg because the e3 editor is
> not working. Even from the command line "e3 /etc/modules" does not open
> the file. For all files that need to be edited, you have to use the vim
> editor.

I confirm this  doesn't work for i486/geode/i686 and will look into it.

> 
> I did not test geoip on Alix, but the rest of functions and programs
> seems to be working fine.
> 
> I'm curious if anyone can fix any of this.

Other issues hopefully as well, but after the one above....

kp

> Kind regards
> Otto
> 
> 
> 
> ------------------------------------------------------------------------
> leaf-user mailing list: lea...@li...
> https://lists.sourceforge.net/lists/listinfo/leaf-user
> Support Request -- http://leaf-project.org/

[leaf-user] 7.5.0 on Alix

[Otto H. - T. <ott...@te...>]

Dear list users,
Probably no one has tested versions 7.5.0 on Alix boards, because there 
are several problems with it.

I used packages from this archive:
Bering-uClibc_7.5.0_geode_syslinux_serial115200

On boot I saw the following warnings:
[ 36.334528] leds-gpio leds-gpio: error -ENOENT: Failed to get GPIO 
'geode-leds/alix:0'
[ 36.342591] leds-gpio leds-gpio: probe with driver leds-gpio failed 
with error -2

After boot I get "firewall login:" on the serial console, but I can't 
log in. I can't type any letter because the console on serial port ttyS0 
is dead, so I can't even create a root password.

So I replaced configdb.lrp with one created on another machine.
Now I am able to log in via dropbear.

But I am not able to use the menu system lrcfg because the e3 editor is 
not working. Even from the command line "e3 /etc/modules" does not open 
the file. For all files that need to be edited, you have to use the vim 
editor.

I did not test geoip on Alix, but the rest of functions and programs 
seems to be working fine.

I'm curious if anyone can fix any of this.

Kind regards
Otto

Re: [leaf-user] geoip

[Otto H. - T. <ott...@te...>]

Dears,

I'll answer for myself.
I updated the APU to latest V7.5.0 x86_64 and geoip doesn't work here 
either.

So I tried many versions and the last working version with filtering 
according to geoip country codes is V6.2.7.

All versions of 7.X can't filter by country code.
The 7.X versions probably do not have country code filtering enabled in 
the kernel.

Best regards
Otto


Dne 21.03.2025 v 20:16 Otto Halák - TeleLarm napsal(a):
> Dears,
> running V7.5.0-rc1
> 
> Installed geoip and xt_add packages.
> 
> Put xt_geoip module to /etc/modules:
> lsmod | grep xt_geo*
> xt_geoip 12288 0 - Live 0xffffffffc066f000 (O)
> x_tables 36864 16 xt_comment,ipt_REJECT,xt_addrtype,iptable_nat,
> xt_mark,iptable_mangle,xt_tcpudp,xt_CT,iptable_raw,xt_multiport,
> xt_conntrack,xt_NFLOG,xt_LOG,iptable_filter,ip_tables,xt_geoip,
> Live 0xffffffffc065b000
> 
> Path in shorewall config to geoip database is correct:
> GEOIPDIR=/usr/share/xt_geoip/LE
> 
> APU is LE:
> echo -n I | od -to2 | head -n1 | cut -f2 -d" " | cut -c6
> 1
> 
> The database is on the right place:
> ls /usr/share/xt_geoip/LE
> A1.iv4  BH.iv6  CO.iv4  FM.iv6  HT.iv4  KY.iv6  MQ.iv4  PE.iv6  SI.iv4
> A1.iv6  BI.iv4  CO.iv6  FO.iv4  HT.iv6  KZ.iv4  MQ.iv6  PF.iv4  SI.iv6
> A2.iv4  BI.iv6  CR.iv4  FO.iv6  HU.iv4  KZ.iv6  MR.iv4  PF.iv6  SJ.iv4
> A2.iv6  BJ.iv4  CR.iv6  FR.iv4  HU.iv6  LA.iv4  MR.iv6  PG.iv4  SJ.iv6
> AD.iv4  BJ.iv6  CU.iv4  FR.iv6  ID.iv4  LA.iv6  MS.iv4  PG.iv6  SK.iv4
> etc...
> 
> The same database I use on older machine where it works like a charm.
> 
> But shorewall still complain when compiling rules:
> ERROR: A country-code require GeoIP Match in your kernel and iptables / 
> etc/shorewall/rules (line 96)
> 
> Any idea what might be wrong?
> 
> Otto
> 

[leaf-user] geoip

[Otto H. - T. <ott...@te...>]

Dears,
running V7.5.0-rc1

Installed geoip and xt_add packages.

Put xt_geoip module to /etc/modules:
lsmod | grep xt_geo*
xt_geoip 12288 0 - Live 0xffffffffc066f000 (O)
x_tables 36864 16 xt_comment,ipt_REJECT,xt_addrtype,iptable_nat,
xt_mark,iptable_mangle,xt_tcpudp,xt_CT,iptable_raw,xt_multiport,
xt_conntrack,xt_NFLOG,xt_LOG,iptable_filter,ip_tables,xt_geoip,
Live 0xffffffffc065b000

Path in shorewall config to geoip database is correct:
GEOIPDIR=/usr/share/xt_geoip/LE

APU is LE:
echo -n I | od -to2 | head -n1 | cut -f2 -d" " | cut -c6
1

The database is on the right place:
ls /usr/share/xt_geoip/LE
A1.iv4  BH.iv6  CO.iv4  FM.iv6  HT.iv4  KY.iv6  MQ.iv4  PE.iv6  SI.iv4
A1.iv6  BI.iv4  CO.iv6  FO.iv4  HT.iv6  KZ.iv4  MQ.iv6  PF.iv4  SI.iv6
A2.iv4  BI.iv6  CR.iv4  FO.iv6  HU.iv4  KZ.iv6  MR.iv4  PF.iv6  SJ.iv4
A2.iv6  BJ.iv4  CR.iv6  FR.iv4  HU.iv6  LA.iv4  MR.iv6  PG.iv4  SJ.iv6
AD.iv4  BJ.iv6  CU.iv4  FR.iv6  ID.iv4  LA.iv6  MS.iv4  PG.iv6  SK.iv4
etc...

The same database I use on older machine where it works like a charm.

But shorewall still complain when compiling rules:
ERROR: A country-code require GeoIP Match in your kernel and iptables 
/etc/shorewall/rules (line 96)

Any idea what might be wrong?

Otto

-- 
Tento e-mail byl antivirovým softwarem AVG zkontrolován na viry.
www.avg.com

[leaf-user] local https with lighted

[Victor M. <vic...@so...>]

I just setup 7.4.0 and  https for lighttpd for managing the firewall
locally 

 Make sure openssl is loaded 

If not 

apkg -i openssl 

 openssl should be listed in leaf.cfg 

…. 

mkdir /etc/lighttpd/certs 

cd /etc/lighttpd/certs 

openssl req -new -x509 -keyout lighttpd.pem -out lighttpd.pem -days 365
-nodes 

       openssl will create the pem file 

        I entered country code US and "." for other questions 

chmod 400 lighttpd.pem 

cd .. 

edit /etc/lighttpd.conf 

add this to end of file 

$SERVER["socket"] == "*:443"{ 

    ssl.engine  =  "enable" 

    ssl.pemfile = "/etc/lighttpd/certs/lighttpd.pem" 

} 

….. 

lrcfg 

edit local.cfg 

add this to end of the file 

/etc/lighttpd/certs/lighttpd.pem 

Make sure /etc/shorewall/rules includes the something like this: 

HTTPS(ACCEPT)       loc:your.local.machine.ip,other.local.ip    fw 

Save configuration 

You may have to 

systemctl restart shorewall 

systemctl restart lighttpd 

When accessing your router, your browser will warn you that the
certificate should not be trusted but it will encrypt local connections
and allow you to manage your router with webconf. 

Victor

Re: [leaf-user] tmpfs

[Boris <bo...@ca...>]

Hej Erich,
hej all,

Am 07.12.24 um 20:12 schrieb Erich Titl:
> 
> 
> Am 07.12.2024 um 19:42 schrieb Boris via leaf-user:
>> Hej Erich,
>>
>> Am 02.12.24 um 17:38 schrieb Erich Titl:
>>>
>>> If the log is somehow controlled by the hostapd daemon then of course 
>>> restarting this would have the desired effect.
>>
>> Do I manage to make the hostapd restarted by setting DAEMON=hostapd in
>> /etc/logrotate.d/hostapd ?
> 
> Yes

I'd like to give a final feedback for this topic:

By setting
DAEMON=hostapd
METHOD=restart
in /etc/logrotate.d/hostapd , my initial issue is solved.
With the restart the hostapd daemon gives the logfile free, it is then 
possible to logrotate it and /var/log does not raise to 100% any longer. 
Fine!
Thanks for sharing your knowledge!

I wish you merry Christmas and a happy new year!

Boris

Re: [leaf-user] tmpfs

[Erich T. <eri...@th...>]

Am 07.12.2024 um 19:42 schrieb Boris via leaf-user:
> Hej Erich,
> 
> Am 02.12.24 um 17:38 schrieb Erich Titl:
>>
>> If the log is somehow controlled by the hostapd daemon then of course 
>> restarting this would have the desired effect.
> 
> Do I manage to make the hostapd restarted by setting DAEMON=hostapd in
> /etc/logrotate.d/hostapd ?

Yes

cheers

ET

-- 
„Wer von seinem Tag nicht zwei Drittel für sich hat, ist ein Sklave.“
―Friedrich Nietzsche

Re: [leaf-user] tmpfs

[Boris <bo...@ca...>]

Hej Erich,

Am 02.12.24 um 17:38 schrieb Erich Titl:
> 
> If the log is somehow controlled by the hostapd daemon then of course 
> restarting this would have the desired effect.

Do I manage to make the hostapd restarted by setting DAEMON=hostapd in
/etc/logrotate.d/hostapd ?
I would like to try this.

Thanks,

Boris

Re: [leaf-user] tmpfs

[Boris <bo...@ca...>]

Hej Andrew,

no, no hostapd_cli on that box....

Boris

Am 03.12.24 um 10:44 schrieb Andrew:
> hi.
> 
> hostapd_cli RELOG should re-open logfile (it hostapd_cli is present in 
> system).
> 
> but it's better to use syslog...
> 
> 
> On 12/2/24 20:15, Erich Titl wrote:
>> Hi Boris
>>
>> Am 02.12.2024 um 17:59 schrieb Boris via leaf-user:
>>> Hej Erich,
>>>
>>> Am 02.12.24 um 17:38 schrieb Erich Titl:
>>>> Hi Boris
>>>>
>>>> Am 02.12.2024 um 16:36 schrieb Boris via leaf-user:
>>>>> Am 25.11.24 um 17:28 schrieb KP.Kirchdoerfer:
>>>>>> Hi,
>>>>>>
>>>> ....>
>>>>> not too big but wrong as on the start of the thread....
>>>>>
>>>>> # lsof | grep /var/log/
>>>>> [snip]
>>>>> 23822    /usr/sbin/ntpd    4    /var/log/ntpd
>>>>> 23822    /usr/sbin/ntpd    5 /var/log/ntpstats/loopstats.20241202 
>>>>> (deleted)
>>>>> 23822    /usr/sbin/ntpd    8 /var/log/ntpstats/peerstats.20241202 
>>>>> (deleted)
>>>>> 27345    /usr/sbin/hostapd    3    /var/log/hostapd.log (deleted)
>>>>
>>>> So the ntp daemon still had these files under control but they were 
>>>> deleted by, maybe logrotate.
>>>
>>> .... and the hostapd daemon also does.
>>
>> Which implies that hostapd does not log to syslog. So either we change 
>> this or we have to restart hostapd in the logrotate settings.
>>
>> ET
>>
> 
> ------------------------------------------------------------------------
> leaf-user mailing list: lea...@li...
> https://lists.sourceforge.net/lists/listinfo/leaf-user
> Support Request -- http://leaf-project.org/

Re: [leaf-user] OpenVPN Issues

[Robert K C. J. -I. F. D. Corp. <bco...@in...>]

   In my case, I had created a DNAT rule that globally passed udp traffic
   to another box via DNAT.   I think I was testing something....  But
   when I found that, everything made sense.

   I am definitely having another issue that I don't believe was caused by
   my incompetence.

   When restarting openvpn -sometimes- I will get an error like this:

   dpyroute# /etc/init.d/openvpn restart
   Stopping virtual private network daemon:rm: can't remove
   '/var/run/openvpn.c_bieri_dpyroute.pid': No such file or directory

   When I look at /var/run, that file is indeed gone, but the .status file
   remains, and any other openvpn processes are still running and their
   .pid files (and .status) are still there.

   If I remark out the rm portion of the stop_vpn subroutine, this problem
   disappears.  It seems like the kill line above it also removes the pid
   file.

   stop_vpn () {
     kill `cat $PIDFILE` || true
     #rm $PIDFILE
     rm -f /var/run/openvpn.$NAME.status 2> /dev/null
   }

   - Bob

   On 12/6/2024 1:42:33 AM, Otto Halák - TeleLarm wrote:

     Hello Robert,
     I faced similar problem and it was caused by statement "routefilter"
     in /etc/shorewall/interfaces, see:
     #ZONE           INTERFACE               OPTIONS
     net             eth0                    dhcp,routefilter
     loc             eth1                    dhcp,routeback
     vpn             tun+
     I used routefilter form many many years but it started to cause
     problems with newer leafs.
     Without routefilter OpenVPN works like a charm.
     Otto

--
Robert K Coffman Jr.
Info From Data Corp.
3307249000
[1]su...@in...

References

   1. mailto:su...@in...

Re: [leaf-user] OpenVPN Issues

[Otto H. - T. <ott...@te...>]

Hello Robert,
I faced similar problem and it was caused by statement "routefilter" in 
/etc/shorewall/interfaces, see:

#ZONE           INTERFACE               OPTIONS
net             eth0                    dhcp,routefilter
loc             eth1                    dhcp,routeback
vpn             tun+

I used routefilter form many many years but it started to cause problems 
with newer leafs.
Without routefilter OpenVPN works like a charm.

Otto


-- 
Tento e-mail byl antivirovým softwarem AVG zkontrolován na viry.
www.avg.com

Re: [leaf-user] OpenVPN Issues

[Robert K C. J. -I. F. D. Corp. <bco...@in...>]

   When you log in to IRC for OpenVPN support, there is a message that
   says "your problem is probably firewall."

   This was....  Sorry for the noise.

   - Robert

   On 12/5/2024 9:36:19 AM, Robert K Coffman Jr. -Info From Data Corp.
   wrote:

   Marko,

   Yes - I was aware of that and bummed out when I found out I had a fleet
   of SHA1 certs out there.  I have some people (road warriors - is this
   term still used?) using the old certs but on different (client)
   firewalls and I have added a config option to allow them: tls-cipher
   "DEFAULT:@SECLEVEL=0"  (does not disable encryption, contrary to some
   postings on the internet, but I understand why this is not a permanent
   solution for them).

   I issued new SHA256 certs prior to this upgrade for my point to point
   VPNs, but even if the certs were bad, the service would normally
   respond or log an error saying so.  It does neither.

   But that being said, these were working even after the upgrade.  It
   appears to me that the service stops accepting connections - in some
   cases - after startup.  I've eliminated pwnage as the cause by building
   a new server from scratch and testing it on an isolated network, but I
   have not ruled out some kind of DoS.

   My busiest servers have about 20 point to point connections, but they
   are largely idle most of the time.  One thought I had was a lack of
   resources (specifically memory) because these are VMs and historically,
   I could get away with some meager RAM allocations - and I recently
   changed DNSMASQ to have a larger cache - but adding RAM to them did not
   have any effect on this problem.

   Is there somewhere I can find out which was the last Leaf version
   before OpenVPN 2.6?

   - Robert


   On 12/4/2024 6:48:34 PM, marko via leaf-user wrote:

Hi Robert,

I use OpenVPN 7.3.1.1 also on a standard upgrade path.  My system works ok,
though it is not busy.

One thing that has changed over time is the sha security level that the
scripts use when creating the machine keys.  It is/was hard coded into the
easyRSA scripts.

It would be worth ruling that one out first.

cheers
marko


On Thursday, 5 December 2024 7:36:42 AM AEDT Robert K Coffman Jr. -Info From
Data Corp. wrote:

   I'm having serious issues with OpenVPN, starting after an upgrade to
   7.3.1.1 (OpenVPN 2.6.10).

   Some or all of my OpenVPN servers exhibit a behavior where they stop
   accepting connections from clients.  What is very strange is that after
   the upgrade, things were fine - only later did this problem start to
   occur.  I made a copy of an affected box and eliminated every possible
   source of a potential issue - disabling shorewall, placing the server
   on the same RFC1918 subnet (unmanaged switch), disabling the HMAC
   signing, running OpenVPN as root - and it just refused to accept
   connections.  We did a packet capture, and we see an intermittent
   packet from the client on the server, but no response from the server.

   I upgraded two of the affected boxes to the latest Leaf beta (OpenVPN
   2.6.12) and on one of them, it started to allow connections again, but
   not from every client.  On the other, it allowed one connection, and
   then - no more.

   Additionally, and probably unrelated, with these OpenVPN versions,
   there seems to be a bug in the startup script.  Issuing
   "/etc/init.d/openvpn restart" sometimes (usually) results in this kind
   of error:

   Stopping virtual private network daemon:rm: can't remove
   '/var/run/openvpn.c_ifdroute_sweitzer.pid': No such file or directory

   And the daemon doesn't restart....  Issuing the same command again
   usually starts it up successfully.

   I am at a complete loss to explain this.  Even a reboot doesn't resolve
   the connection issue once it starts.

   Anyone else seeing issues with OpenVPN running as a server?  This does
   not seem to affect when running as a client.

   Thanks -

   Robert
--
Robert K Coffman Jr.
Info From Data Corp.
3307249000
[[[1]1]1]su...@in...

References

   1. [2][2]mailto:su...@in...

------------------------------------------------------------------------
leaf-user mailing list: [[3]3]lea...@li...
[4][4]https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- [5][5]http://leaf-project.org/





------------------------------------------------------------------------
leaf-user mailing list: [[6]6]lea...@li...
[7][7]https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- [8][8]http://leaf-project.org/

--
Robert K Coffman Jr.
Info From Data Corp.
3307249000
[[9]9]su...@in...

References

   1. [10]mailto:1]su...@in...
   2. [11]mailto:su...@in...
   3. [12]mailto:lea...@li...
   4. [13]https://lists.sourceforge.net/lists/listinfo/leaf-user
   5. [14]http://leaf-project.org/
   6. [15]mailto:lea...@li...
   7. [16]https://lists.sourceforge.net/lists/listinfo/leaf-user
   8. [17]http://leaf-project.org/
   9. [18]mailto:su...@in...

------------------------------------------------------------------------
leaf-user mailing list: [19]lea...@li...
[20]https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- [21]http://leaf-project.org/

--
Robert K Coffman Jr.
Info From Data Corp.
3307249000
[22]su...@in...

References

   1. mailto:1]1]su...@in...
   2. mailto:su...@in...
   3. mailto:3]lea...@li...
   4. https://lists.sourceforge.net/lists/listinfo/leaf-user
   5. http://leaf-project.org/
   6. mailto:6]lea...@li...
   7. https://lists.sourceforge.net/lists/listinfo/leaf-user
   8. http://leaf-project.org/
   9. mailto:9]su...@in...
  10. mailto:1
  11. mailto:su...@in...
  12. mailto:lea...@li...
  13. https://lists.sourceforge.net/lists/listinfo/leaf-user
  14. http://leaf-project.org/
  15. mailto:lea...@li...
  16. https://lists.sourceforge.net/lists/listinfo/leaf-user
  17. http://leaf-project.org/
  18. mailto:su...@in...
  19. mailto:lea...@li...
  20. https://lists.sourceforge.net/lists/listinfo/leaf-user
  21. http://leaf-project.org/
  22. mailto:su...@in...

Re: [leaf-user] OpenVPN Issues

[Robert K C. J. -I. F. D. Corp. <bco...@in...>]

   Marko,

   Yes - I was aware of that and bummed out when I found out I had a fleet
   of SHA1 certs out there.  I have some people (road warriors - is this
   term still used?) using the old certs but on different (client)
   firewalls and I have added a config option to allow them: tls-cipher
   "DEFAULT:@SECLEVEL=0"  (does not disable encryption, contrary to some
   postings on the internet, but I understand why this is not a permanent
   solution for them).

   I issued new SHA256 certs prior to this upgrade for my point to point
   VPNs, but even if the certs were bad, the service would normally
   respond or log an error saying so.  It does neither.

   But that being said, these were working even after the upgrade.  It
   appears to me that the service stops accepting connections - in some
   cases - after startup.  I've eliminated pwnage as the cause by building
   a new server from scratch and testing it on an isolated network, but I
   have not ruled out some kind of DoS.

   My busiest servers have about 20 point to point connections, but they
   are largely idle most of the time.  One thought I had was a lack of
   resources (specifically memory) because these are VMs and historically,
   I could get away with some meager RAM allocations - and I recently
   changed DNSMASQ to have a larger cache - but adding RAM to them did not
   have any effect on this problem.

   Is there somewhere I can find out which was the last Leaf version
   before OpenVPN 2.6?

   - Robert


   On 12/4/2024 6:48:34 PM, marko via leaf-user wrote:

Hi Robert,

I use OpenVPN 7.3.1.1 also on a standard upgrade path.  My system works ok,
though it is not busy.

One thing that has changed over time is the sha security level that the
scripts use when creating the machine keys.  It is/was hard coded into the
easyRSA scripts.

It would be worth ruling that one out first.

cheers
marko


On Thursday, 5 December 2024 7:36:42 AM AEDT Robert K Coffman Jr. -Info From
Data Corp. wrote:

   I'm having serious issues with OpenVPN, starting after an upgrade to
   7.3.1.1 (OpenVPN 2.6.10).

   Some or all of my OpenVPN servers exhibit a behavior where they stop
   accepting connections from clients.  What is very strange is that after
   the upgrade, things were fine - only later did this problem start to
   occur.  I made a copy of an affected box and eliminated every possible
   source of a potential issue - disabling shorewall, placing the server
   on the same RFC1918 subnet (unmanaged switch), disabling the HMAC
   signing, running OpenVPN as root - and it just refused to accept
   connections.  We did a packet capture, and we see an intermittent
   packet from the client on the server, but no response from the server.

   I upgraded two of the affected boxes to the latest Leaf beta (OpenVPN
   2.6.12) and on one of them, it started to allow connections again, but
   not from every client.  On the other, it allowed one connection, and
   then - no more.

   Additionally, and probably unrelated, with these OpenVPN versions,
   there seems to be a bug in the startup script.  Issuing
   "/etc/init.d/openvpn restart" sometimes (usually) results in this kind
   of error:

   Stopping virtual private network daemon:rm: can't remove
   '/var/run/openvpn.c_ifdroute_sweitzer.pid': No such file or directory

   And the daemon doesn't restart....  Issuing the same command again
   usually starts it up successfully.

   I am at a complete loss to explain this.  Even a reboot doesn't resolve
   the connection issue once it starts.

   Anyone else seeing issues with OpenVPN running as a server?  This does
   not seem to affect when running as a client.

   Thanks -

   Robert
--
Robert K Coffman Jr.
Info From Data Corp.
3307249000
[[1]1]su...@in...

References

   1. [2]mailto:su...@in...

------------------------------------------------------------------------
leaf-user mailing list: [3]lea...@li...
[4]https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- [5]http://leaf-project.org/





------------------------------------------------------------------------
leaf-user mailing list: [6]lea...@li...
[7]https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- [8]http://leaf-project.org/

--
Robert K Coffman Jr.
Info From Data Corp.
3307249000
[9]su...@in...

References

   1. mailto:1]su...@in...
   2. mailto:su...@in...
   3. mailto:lea...@li...
   4. https://lists.sourceforge.net/lists/listinfo/leaf-user
   5. http://leaf-project.org/
   6. mailto:lea...@li...
   7. https://lists.sourceforge.net/lists/listinfo/leaf-user
   8. http://leaf-project.org/
   9. mailto:su...@in...

Re: [leaf-user] OpenVPN Issues

[marko <le...@me...>]

Hi Robert,

I use OpenVPN 7.3.1.1 also on a standard upgrade path.  My system works ok, 
though it is not busy.  

One thing that has changed over time is the sha security level that the 
scripts use when creating the machine keys.  It is/was hard coded into the 
easyRSA scripts.   

It would be worth ruling that one out first.

cheers
marko


On Thursday, 5 December 2024 7:36:42 AM AEDT Robert K Coffman Jr. -Info From 
Data Corp. wrote:
>    I'm having serious issues with OpenVPN, starting after an upgrade to
>    7.3.1.1 (OpenVPN 2.6.10).
> 
>    Some or all of my OpenVPN servers exhibit a behavior where they stop
>    accepting connections from clients.  What is very strange is that after
>    the upgrade, things were fine - only later did this problem start to
>    occur.  I made a copy of an affected box and eliminated every possible
>    source of a potential issue - disabling shorewall, placing the server
>    on the same RFC1918 subnet (unmanaged switch), disabling the HMAC
>    signing, running OpenVPN as root - and it just refused to accept
>    connections.  We did a packet capture, and we see an intermittent
>    packet from the client on the server, but no response from the server.
> 
>    I upgraded two of the affected boxes to the latest Leaf beta (OpenVPN
>    2.6.12) and on one of them, it started to allow connections again, but
>    not from every client.  On the other, it allowed one connection, and
>    then - no more.
> 
>    Additionally, and probably unrelated, with these OpenVPN versions,
>    there seems to be a bug in the startup script.  Issuing
>    "/etc/init.d/openvpn restart" sometimes (usually) results in this kind
>    of error:
> 
>    Stopping virtual private network daemon:rm: can't remove
>    '/var/run/openvpn.c_ifdroute_sweitzer.pid': No such file or directory
> 
>    And the daemon doesn't restart....  Issuing the same command again
>    usually starts it up successfully.
> 
>    I am at a complete loss to explain this.  Even a reboot doesn't resolve
>    the connection issue once it starts.
> 
>    Anyone else seeing issues with OpenVPN running as a server?  This does
>    not seem to affect when running as a client.
> 
>    Thanks -
> 
>    Robert
> --
> Robert K Coffman Jr.
> Info From Data Corp.
> 3307249000
> [1]su...@in...
> 
> References
> 
>    1. mailto:su...@in...
> 
> ------------------------------------------------------------------------
> leaf-user mailing list: lea...@li...
> https://lists.sourceforge.net/lists/listinfo/leaf-user
> Support Request -- http://leaf-project.org/