astlinux-devel Mailing List for AstLinux

Hi Devs,

We have made good progress on getting a major kernel upgrade (3.16.x) for the future AstLinux 1.3.x series.
Special thanks to Michael Keuter for testing and research.

Particularly for those of you who build your own images, here are a few tips:

1) The native build system now requires "bc" to build the kernel, this has been added to the Prerequisites - Package lists.


2) If you have any custom .config's they need to be updated, in particular the following entries:

For i586:
--
BR2_TOOLCHAIN_EXTERNAL_PATH="$(HOME)/astlinux/x-tools-1.20.0-3.16/i586-unknown-linux-gnu"
BR2_LINUX_KERNEL_CUSTOM_TARBALL_LOCATION="https://www.kernel.org/pub/linux/kernel/v3.x/linux-3.16.43.tar.gz"
--

For x86_64:
--
BR2_TOOLCHAIN_EXTERNAL_PATH="$(HOME)/astlinux/x-tools-1.20.0-3.16/x86_64-unknown-linux-gnu"
BR2_LINUX_KERNEL_CUSTOM_TARBALL_LOCATION="https://www.kernel.org/pub/linux/kernel/v3.x/linux-3.16.43.tar.gz"
--

I would suggest removing (requires sudo) or renaming the previous "$(HOME)/astlinux/x-tools-1.20.0-3.2p1" directory to make sure the old toolchain does not get accidentally used.


3) The i586 and x86_64 toolchains need to be rebuilt with the new kernel header files, you will be automatically prompted with the new "crosstool-ng-src/README".  No need to re-install "crosstool-ng-1.20.0", simply create new toolchains.


The beginning of the new ChangeLog is here:
http://svn.code.sf.net/p/astlinux/code/branches/1.0/docs/ChangeLog.txt

Lonnie

Announcing AstLinux Release: 1.2.10

More Info: AstLinux Project
http://www.astlinux-project.org/

AstLinux 1.2.10 Highlights:
• New package "sngrep" tool for displaying SIP call message flows from a terminal
• New package "netcalc" IPv4 and IPv6 network calculator, also used for dnsmasq configuration
• New package "gntp-send" CLI tool for sending Growl (GNTP) notifications
• Added 'rbash' a restricted login shell /bin/rbash for non-root users
• Added ddclient-curl support allowing mixed IPv4/IPv6 DNS updates and other dynamic DNS features
• Added USB TTY feature to automatically spawn getty for selected usb tty serial devices
• Added support for Hyper-V VM's with hv_netvsc and hv_utils kernel drivers (genx86_64-vm)
• Web Interface enhancements and package upgrades providing important security and bug fixes

Full ChangeLog:
http://svn.code.sf.net/p/astlinux/code/tags/1.2.10/docs/ChangeLog.txt

All users are encouraged to upgrade.

AstLinux Team

Announcing Pre-Release Version: astlinux-1.0-8306

Release Candidate for AstLinux 1.2.10

The AstLinux Team is regularly upgrading packages containing security and bug fixes as well as adding new features of our own.

-- DHCPv6 Client Action Script
http://doc.astlinux-project.org/userdoc:tt-dhcpv6-prefix-delegation#dhcpv6_client_action_script

-- USB TTY Serial Login
http://doc.astlinux-project.org/userdoc:usbtty_serial_login

-- Hyper-V (only genx86_64-vm board type)
http://doc.astlinux-project.org/userdoc:guest_vm_hyperv

-- Restricted User Login
http://doc.astlinux-project.org/userdoc:tt_restricted_user_login

-- Asterisk Call Notification
http://doc.astlinux-project.org/userdoc:tt_asterisk_call_notify

-- Dynamic DNS Client
http://doc.astlinux-project.org/userdoc:tt_dynamic_dns_client

-- sngrep, version 1.4.3, new package, tool for displaying SIP call message flows from a terminal.

These pre-release images are for those who would like to take advantage of the AstLinux development before the next official release, as well as providing testing for the project.

The "AstLinux Pre-Release ChangeLog" and "Repository URL" entries can be found under the "Development" tab of the AstLinux Project web site ...

AstLinux Project -> Development
http://www.astlinux-project.org/dev.html

If you should come across an issue, please report back here ASAP.

AstLinux Team

Announcing Pre-Release Version: astlinux-1.0-8288

The AstLinux Team is regularly upgrading packages containing security and bug fixes as well as adding new features of our own.

-- USB TTY Serial Login
http://doc.astlinux-project.org/userdoc:usbtty_serial_login

-- Hyper-V (only genx86_64-vm board type)
http://doc.astlinux-project.org/userdoc:guest_vm_hyperv

-- Restricted User Login
http://doc.astlinux-project.org/userdoc:tt_restricted_user_login

-- Asterisk Call Notification
http://doc.astlinux-project.org/userdoc:tt_asterisk_call_notify

-- Dynamic DNS Client
http://doc.astlinux-project.org/userdoc:tt_dynamic_dns_client

-- sngrep, version 1.4.2, new package, tool for displaying SIP call message flows from a terminal.

These pre-release images are for those who would like to take advantage of the AstLinux development before the next official release, as well as providing testing for the project.

The "AstLinux Pre-Release ChangeLog" and "Repository URL" entries can be found under the "Development" tab of the AstLinux Project web site ...

AstLinux Project -> Development
http://www.astlinux-project.org/dev.html

While these images are considered 'stable', the lack of testing will not make these images suitable for critical production systems.

If you should come across an issue, please report back here.

AstLinux Team

I did not know about resize.  Thanks.

David

On Wed, May 3, 2017 at 10:19 PM, Lonnie Abelbeck <li...@lo...>
wrote:

> As a tip, you can manually type "resize" after you login on a serial
> console to do the same.
>
> Due to the lack of responses we probably should keep "/dev/ttyS*" pure and
> no fancy stuff.
>
> A person can always enable "USB TTY Serial Login"
> https://doc.astlinux-project.org/userdoc:usbtty_serial_login even if
> there is a serial port.
> for those cases when an non-network, out-of-band login is needed.  The
> "resize" is automatic there.
>
> Lonnie
>
>
> On May 3, 2017, at 8:55 PM, David Kerr <Da...@Ke...> wrote:
>
> > So I rarely have to resort to serial terminal use... usually only when I
> screw up.  However on those rare occasions that I do have to go serial it
> would be very very nice to be able to increase the screen size.  In
> particular 24x80 does restrict how many e.g. syslog messages are visible at
> once.  As I recall whatever terminal s/w I use doesn't have a scroll buffer
> I can use to go back to see messages that already scrolled off.
> >
> > David
> >
> > On Mon, May 1, 2017 at 8:12 PM, Lonnie Abelbeck <
> li...@lo...> wrote:
> > Hi Devs,
> >
> > When adding the new "USB TTY Serial Login" feature, one thing we did in
> the /etc/profile is to call the "resize" command to query the terminal to
> automatically determine the LINES and COLUMNS and update "stty -a".
> > --
> > # Set LINES and COLUMNS for USB TTY serial devices
> > if [ -x /usr/bin/resize ]; then
> >   case $(tty) in
> >     /dev/ttyUSB*) resize >/dev/null ;;
> >   esac
> > fi
> > --
> > This works very nicely, and makes ncurses apps work as expected for an
> arbitrary terminal window size, rather than assuming the default 24x80.
> >
> > Simple question, should we do the same for "/dev/ttyS*" for standard
> serial consoles ?
> >
> > You may wonder how "resize" works, a vt100 terminal allows an escape
> sequence to "Query Cursor Position" after moving to ROW;COLUMN position
> 999;999 pinned at lower-right, lastly restore cursor back to where it
> started. "resize" reads the data sent back indicating the size of the
> terminal window.
> >
> > So clearly this will only work if you are emulating a vt100 or some
> later ANSI flavor, but chances are you do.  But what if you don't, then you
> might see a few goofy escape sequences shown and the "resize" command waits
> for up to 3 seconds to get a reply before giving-up and continuing as
> normal.
> >
> > I'll gladly add "/dev/ttyS*" if people like the idea, but will leave it
> as is until there is demand for the change.
> >
> > Lonnie
>
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>

As a tip, you can manually type "resize" after you login on a serial console to do the same.

Due to the lack of responses we probably should keep "/dev/ttyS*" pure and no fancy stuff.

A person can always enable "USB TTY Serial Login" https://doc.astlinux-project.org/userdoc:usbtty_serial_login even if there is a serial port.
for those cases when an non-network, out-of-band login is needed.  The "resize" is automatic there.

Lonnie


On May 3, 2017, at 8:55 PM, David Kerr <Da...@Ke...> wrote:

> So I rarely have to resort to serial terminal use... usually only when I screw up.  However on those rare occasions that I do have to go serial it would be very very nice to be able to increase the screen size.  In particular 24x80 does restrict how many e.g. syslog messages are visible at once.  As I recall whatever terminal s/w I use doesn't have a scroll buffer I can use to go back to see messages that already scrolled off.
> 
> David
> 
> On Mon, May 1, 2017 at 8:12 PM, Lonnie Abelbeck <li...@lo...> wrote:
> Hi Devs,
> 
> When adding the new "USB TTY Serial Login" feature, one thing we did in the /etc/profile is to call the "resize" command to query the terminal to automatically determine the LINES and COLUMNS and update "stty -a".
> --
> # Set LINES and COLUMNS for USB TTY serial devices
> if [ -x /usr/bin/resize ]; then
>   case $(tty) in
>     /dev/ttyUSB*) resize >/dev/null ;;
>   esac
> fi
> --
> This works very nicely, and makes ncurses apps work as expected for an arbitrary terminal window size, rather than assuming the default 24x80.
> 
> Simple question, should we do the same for "/dev/ttyS*" for standard serial consoles ?
> 
> You may wonder how "resize" works, a vt100 terminal allows an escape sequence to "Query Cursor Position" after moving to ROW;COLUMN position 999;999 pinned at lower-right, lastly restore cursor back to where it started. "resize" reads the data sent back indicating the size of the terminal window.
> 
> So clearly this will only work if you are emulating a vt100 or some later ANSI flavor, but chances are you do.  But what if you don't, then you might see a few goofy escape sequences shown and the "resize" command waits for up to 3 seconds to get a reply before giving-up and continuing as normal.
> 
> I'll gladly add "/dev/ttyS*" if people like the idea, but will leave it as is until there is demand for the change.
> 
> Lonnie

​No opinion on this one.  I always change to 115200 as one of the first
things I do anyway.

David​

On Wed, May 3, 2017 at 8:15 PM, Darrick Hartman <dha...@dj...>
wrote:

> My vote would be to change it at a later date as part of a bigger change
> set ( say like a kernel bump ).
>
> -----Original Message-----
> From: Michael Knill [mailto:mic...@ip...]
> Sent: Wednesday, May 3, 2017 4:52 PM
> To: AstLinux Developers Mailing List <ast...@li...
> >
> Subject: Re: [Astlinux-devel] (geni586|genx86_64)-serial 115200 baud
> default?
>
> I vote for 1. Do nothing.
> It's a one liner as part of my standard build process.
>
> Regards
> Michael Knill
>
> -----Original Message-----
> From: Lonnie Abelbeck <li...@lo...>
> Reply-To: AstLinux Developers Mailing List <astlinux-devel@lists.
> sourceforge.net>
> Date: Thursday, 4 May 2017 at 4:06 am
> To: AstLinux Developers Mailing List <ast...@li...
> >
> Subject: [Astlinux-devel] (geni586|genx86_64)-serial 115200 baud default?
>
> Hi Devs,
>
> Question: Is it time to change our RUNNIX and geni586-serial and
> genx86_64-serial board types to default to 115200 baud consoles ?
>
> The good news, for new installs this is only a documentation change.
>
> The bad news, for existing installs, a new (115200) run image would be a
> mismatch between RUNNIX and possibly the BIOS if serial console redirection
> was enabled.  Messy.
>
> Recall we have a command 'setconsole-speed-tty" that edits the
> /etc/inittab on unionfs and /oldroot/cdrom/syslinux.cfg on the FAT16
> (RUNNIX) partition to override any default settings.
>
> Therefore for an existing install, a user would either have to:
>
> 1) After upgrade: "setconsole-speed-tty 19200" to return back to using
> 19200 baud.
>
> 2) Update to a RUNNIX with a 115200 default then upgrade to the new 115200
> AstLinux image .. then change any serial BIOS console redirection if needed.
>
> So, the options as I see them ...
>
> 1) Keep 19200 as the console default, do nothing.
>
> 2) Change the console default to 115200 and document how users need to
> adapt to using 115200 baud.
>
> 3) Change the console default to 115200, but using the FIRSTRUN init.d
> script automatically call "setconsole-speed-tty 19200" if syslinux.cfg
> (RUNNIX) was configured for 19200 to keep things at 19200 for the future.
> 3a) Note: still not perfect as a baud mis-match would occur one time
> before "setconsole-speed-tty 19200" could be called.
>
> Of course a baud rate mismatch between the BIOS, RUNNIX or AstLInux will
> not effect booting properly, just serial console access.
>
> Unless we have a consensus for a change, we will leave it as is.
>
> Lonnie
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most engaging
> tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most engaging
> tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>

So I rarely have to resort to serial terminal use... usually only when I
screw up.  However on those rare occasions that I do have to go serial it
would be very very nice to be able to increase the screen size.  In
particular 24x80 does restrict how many e.g. syslog messages are visible at
once.  As I recall whatever terminal s/w I use doesn't have a scroll buffer
I can use to go back to see messages that already scrolled off.

David

On Mon, May 1, 2017 at 8:12 PM, Lonnie Abelbeck <li...@lo...>
wrote:

> Hi Devs,
>
> When adding the new "USB TTY Serial Login" feature, one thing we did in
> the /etc/profile is to call the "resize" command to query the terminal to
> automatically determine the LINES and COLUMNS and update "stty -a".
> --
> # Set LINES and COLUMNS for USB TTY serial devices
> if [ -x /usr/bin/resize ]; then
>   case $(tty) in
>     /dev/ttyUSB*) resize >/dev/null ;;
>   esac
> fi
> --
> This works very nicely, and makes ncurses apps work as expected for an
> arbitrary terminal window size, rather than assuming the default 24x80.
>
> Simple question, should we do the same for "/dev/ttyS*" for standard
> serial consoles ?
>
> You may wonder how "resize" works, a vt100 terminal allows an escape
> sequence to "Query Cursor Position" after moving to ROW;COLUMN position
> 999;999 pinned at lower-right, lastly restore cursor back to where it
> started. "resize" reads the data sent back indicating the size of the
> terminal window.
>
> So clearly this will only work if you are emulating a vt100 or some later
> ANSI flavor, but chances are you do.  But what if you don't, then you might
> see a few goofy escape sequences shown and the "resize" command waits for
> up to 3 seconds to get a reply before giving-up and continuing as normal.
>
> I'll gladly add "/dev/ttyS*" if people like the idea, but will leave it as
> is until there is demand for the change.
>
> Lonnie
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>

My vote would be to change it at a later date as part of a bigger change set ( say like a kernel bump ).

-----Original Message-----
From: Michael Knill [mailto:mic...@ip...] 
Sent: Wednesday, May 3, 2017 4:52 PM
To: AstLinux Developers Mailing List <ast...@li...>
Subject: Re: [Astlinux-devel] (geni586|genx86_64)-serial 115200 baud default?

I vote for 1. Do nothing. 
It's a one liner as part of my standard build process.

Regards
Michael Knill

-----Original Message-----
From: Lonnie Abelbeck <li...@lo...>
Reply-To: AstLinux Developers Mailing List <ast...@li...>
Date: Thursday, 4 May 2017 at 4:06 am
To: AstLinux Developers Mailing List <ast...@li...>
Subject: [Astlinux-devel] (geni586|genx86_64)-serial 115200 baud default?

Hi Devs,

Question: Is it time to change our RUNNIX and geni586-serial and genx86_64-serial board types to default to 115200 baud consoles ?

The good news, for new installs this is only a documentation change.

The bad news, for existing installs, a new (115200) run image would be a mismatch between RUNNIX and possibly the BIOS if serial console redirection was enabled.  Messy.

Recall we have a command 'setconsole-speed-tty" that edits the /etc/inittab on unionfs and /oldroot/cdrom/syslinux.cfg on the FAT16 (RUNNIX) partition to override any default settings.

Therefore for an existing install, a user would either have to:

1) After upgrade: "setconsole-speed-tty 19200" to return back to using 19200 baud.

2) Update to a RUNNIX with a 115200 default then upgrade to the new 115200 AstLinux image .. then change any serial BIOS console redirection if needed.

So, the options as I see them ...

1) Keep 19200 as the console default, do nothing.

2) Change the console default to 115200 and document how users need to adapt to using 115200 baud.

3) Change the console default to 115200, but using the FIRSTRUN init.d script automatically call "setconsole-speed-tty 19200" if syslinux.cfg (RUNNIX) was configured for 19200 to keep things at 19200 for the future.
3a) Note: still not perfect as a baud mis-match would occur one time before "setconsole-speed-tty 19200" could be called.

Of course a baud rate mismatch between the BIOS, RUNNIX or AstLInux will not effect booting properly, just serial console access.

Unless we have a consensus for a change, we will leave it as is.

Lonnie


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-devel

I vote for 1. Do nothing. 
It's a one liner as part of my standard build process.

Regards
Michael Knill

-----Original Message-----
From: Lonnie Abelbeck <li...@lo...>
Reply-To: AstLinux Developers Mailing List <ast...@li...>
Date: Thursday, 4 May 2017 at 4:06 am
To: AstLinux Developers Mailing List <ast...@li...>
Subject: [Astlinux-devel] (geni586|genx86_64)-serial 115200 baud default?

Hi Devs,

Question: Is it time to change our RUNNIX and geni586-serial and genx86_64-serial board types to default to 115200 baud consoles ?

The good news, for new installs this is only a documentation change.

The bad news, for existing installs, a new (115200) run image would be a mismatch between RUNNIX and possibly the BIOS if serial console redirection was enabled.  Messy.

Recall we have a command 'setconsole-speed-tty" that edits the /etc/inittab on unionfs and /oldroot/cdrom/syslinux.cfg on the FAT16 (RUNNIX) partition to override any default settings.

Therefore for an existing install, a user would either have to:

1) After upgrade: "setconsole-speed-tty 19200" to return back to using 19200 baud.

2) Update to a RUNNIX with a 115200 default then upgrade to the new 115200 AstLinux image .. then change any serial BIOS console redirection if needed.

So, the options as I see them ...

1) Keep 19200 as the console default, do nothing.

2) Change the console default to 115200 and document how users need to adapt to using 115200 baud.

3) Change the console default to 115200, but using the FIRSTRUN init.d script automatically call "setconsole-speed-tty 19200" if syslinux.cfg (RUNNIX) was configured for 19200 to keep things at 19200 for the future.
3a) Note: still not perfect as a baud mis-match would occur one time before "setconsole-speed-tty 19200" could be called.

Of course a baud rate mismatch between the BIOS, RUNNIX or AstLInux will not effect booting properly, just serial console access.

Unless we have a consensus for a change, we will leave it as is.

Lonnie


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-devel

Hi Devs,

Question: Is it time to change our RUNNIX and geni586-serial and genx86_64-serial board types to default to 115200 baud consoles ?

The good news, for new installs this is only a documentation change.

The bad news, for existing installs, a new (115200) run image would be a mismatch between RUNNIX and possibly the BIOS if serial console redirection was enabled.  Messy.

Recall we have a command 'setconsole-speed-tty" that edits the /etc/inittab on unionfs and /oldroot/cdrom/syslinux.cfg on the FAT16 (RUNNIX) partition to override any default settings.

Therefore for an existing install, a user would either have to:

1) After upgrade: "setconsole-speed-tty 19200" to return back to using 19200 baud.

2) Update to a RUNNIX with a 115200 default then upgrade to the new 115200 AstLinux image .. then change any serial BIOS console redirection if needed.

So, the options as I see them ...

1) Keep 19200 as the console default, do nothing.

2) Change the console default to 115200 and document how users need to adapt to using 115200 baud.

3) Change the console default to 115200, but using the FIRSTRUN init.d script automatically call "setconsole-speed-tty 19200" if syslinux.cfg (RUNNIX) was configured for 19200 to keep things at 19200 for the future.
3a) Note: still not perfect as a baud mis-match would occur one time before "setconsole-speed-tty 19200" could be called.

Of course a baud rate mismatch between the BIOS, RUNNIX or AstLInux will not effect booting properly, just serial console access.

Unless we have a consensus for a change, we will leave it as is.

Lonnie

Hi Devs,

When adding the new "USB TTY Serial Login" feature, one thing we did in the /etc/profile is to call the "resize" command to query the terminal to automatically determine the LINES and COLUMNS and update "stty -a".
--
# Set LINES and COLUMNS for USB TTY serial devices
if [ -x /usr/bin/resize ]; then
  case $(tty) in
    /dev/ttyUSB*) resize >/dev/null ;;
  esac
fi
--
This works very nicely, and makes ncurses apps work as expected for an arbitrary terminal window size, rather than assuming the default 24x80.

Simple question, should we do the same for "/dev/ttyS*" for standard serial consoles ?

You may wonder how "resize" works, a vt100 terminal allows an escape sequence to "Query Cursor Position" after moving to ROW;COLUMN position 999;999 pinned at lower-right, lastly restore cursor back to where it started. "resize" reads the data sent back indicating the size of the terminal window.

So clearly this will only work if you are emulating a vt100 or some later ANSI flavor, but chances are you do.  But what if you don't, then you might see a few goofy escape sequences shown and the "resize" command waits for up to 3 seconds to get a reply before giving-up and continuing as normal.

I'll gladly add "/dev/ttyS*" if people like the idea, but will leave it as is until there is demand for the change.

Lonnie

Sounds good and useful to me.

Sent from a mobile device.

Michael Keuter

> Am 01.05.2017 um 15:42 schrieb Lonnie Abelbeck <li...@lo...>:
> 
> Hi Devs,
> 
> The "[Astlinux-users] Qotom Q190G4N-S07 ..." discusses how that particular box has a problem with ethernet NIC offload enabled (default) and libpcap tools.
> 
> We currently automatically disable "tso gso gro" for interfaces that the traffic shaper is applied to, otherwise it won't work properly.
> 
> This is a long running issue with the pfSense folks (albeit Linux generally has more polished NIC drivers), here is a snippet ...
> 
> "The settings for Hardware TCP Segmentation Offload (TSO) and Hardware Large Receive Offload (LRO) under System > Advanced on the Networking tab default to checked (disabled) for good reason. Nearly all hardware/drivers have issues with these settings, and they can lead to throughput issues. Ensure the options are checked."
> 
> https://doc.pfsense.org/index.php/Tuning_and_Troubleshooting_Network_Cards#TSO.2FLRO
> 
> 
> So, while our typical boards / appliances have not demonstrated NIC offload issues (to my knowledge) the Qotom now does and I suspect it won't be the last.
> 
> I'm proposing we add a PHYETH_DISABLE_OFFLOAD rc.conf variable, disabled by default.  We currently have this section:
> --
> ## Physical Ethernet Configuration
> ## If you need to manually specify any speed and duplex settings, you can 
> ## do that here NOTE: This will disable auto-negotiation for any devices 
> ## you enable it for.
> ## Note that this code runs AFTER the ifrename support above.
> ## INTERFACE:speed:duplex
> #PHYETH="eth0:10:half eth1:100:half"
> --
> 
> add...
> --
> ## Disable hardware network interface offloading for the specified offload types.
> ## Note: This applies to all configured ethernet interfaces and VLAN's.
> #PHYETH_DISABLE_OFFLOAD="tso gso gro"
> --
> 
> Advanced configuration could also be done using /mnt/kd/rc.elocal and ethtool, but the PHYETH_DISABLE_OFFLOAD variable would provide a simple quick setup solution.
> 
> Comments ?
> 
> Lonnie
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel

Hi Devs,

The "[Astlinux-users] Qotom Q190G4N-S07 ..." discusses how that particular box has a problem with ethernet NIC offload enabled (default) and libpcap tools.

We currently automatically disable "tso gso gro" for interfaces that the traffic shaper is applied to, otherwise it won't work properly.

This is a long running issue with the pfSense folks (albeit Linux generally has more polished NIC drivers), here is a snippet ...

"The settings for Hardware TCP Segmentation Offload (TSO) and Hardware Large Receive Offload (LRO) under System > Advanced on the Networking tab default to checked (disabled) for good reason. Nearly all hardware/drivers have issues with these settings, and they can lead to throughput issues. Ensure the options are checked."

https://doc.pfsense.org/index.php/Tuning_and_Troubleshooting_Network_Cards#TSO.2FLRO


So, while our typical boards / appliances have not demonstrated NIC offload issues (to my knowledge) the Qotom now does and I suspect it won't be the last.

I'm proposing we add a PHYETH_DISABLE_OFFLOAD rc.conf variable, disabled by default.  We currently have this section:
--
## Physical Ethernet Configuration
## If you need to manually specify any speed and duplex settings, you can 
## do that here NOTE: This will disable auto-negotiation for any devices 
## you enable it for.
## Note that this code runs AFTER the ifrename support above.
## INTERFACE:speed:duplex
#PHYETH="eth0:10:half eth1:100:half"
--

add...
--
## Disable hardware network interface offloading for the specified offload types.
## Note: This applies to all configured ethernet interfaces and VLAN's.
#PHYETH_DISABLE_OFFLOAD="tso gso gro"
--

Advanced configuration could also be done using /mnt/kd/rc.elocal and ethtool, but the PHYETH_DISABLE_OFFLOAD variable would provide a simple quick setup solution.

Comments ?

Lonnie