new one, not sure if you can edit T403

Fixed 1, 2, and 3.

Do you want me to add it to T403 or make a new ticket?

Can you submit bug report please

This patch should also be included in 1.2.x, as i have seem similar behaviour with nightly builds.

Virtualization would work fine. The daemon/server LCDd is just code, and can be configured to run a nCurses "driver". Some other drivers only do parallel port stuff so would do nothing in a virtual environment. Other drivers do serial port and I suppose the data stream could be monitored. The clients (lcdproc, lcdexec, etc) are just programs that push data to LCDd over TCP.

Is there any possibility to test this functionality in some kind of virtualized environment? Or the developer has to own an appliance with lcd screen to check this things?

On further investigation, it seems I can add firewall rules to wwan0 or place wwan0 into a zone-policy. If this is the case, then I may have accomplished what I wanted especially the latter and no bridging required.

Hello, is there a way to easy install kernel source/headers for default kernel used by vyos 1.1.x (3.13.11-1-amd64-vyos)?

So it looks like vpp progressing a bit.
https://github.com/FRRouting/frr/wiki/Alternate-forwarding-planes:-VPP

Awesome! Raised https://github.com/vyos/vyatta-cfg-quagga/pull/16

@dmbaturin @pmoust there is a CLI implementation already!

It's great that it landed in quagga! Really looking forward to the CLI implementation for VyOS.

Thank you.
It looks like you have this compiled to much newer kernel, 4.4.15 while current kernel in VyOS 1.1.7 is 3.13.11-1-amd64-vyos.
So it looks like i need to compile it by my own, but thanks anyway for sharing this ;)

Here you are -

Ups, seems I was wrong in last comment. I'll collect all the files from .deb and post them here.

Well, I don't have access to development vm, where I did this stuff today (remind me on monday, please), but I do have kernel module (the only file in .deb, actually) compiled against 4.4.15-amd64-vyos kernel.

@dmbaturin check this out

Hello,
Is there a chance that ipt_NETFLOW will be included in next release (and if yes, where it is planned to release this version?)
@mickvav Can you share your .deb package please? We need ipt_NETFLOW ASAP. Thanks

In T375#7897, @p10003 wrote:

So one other tiny thing you might try since you have 192.168.0.1/24 (eth0) but different 192.168.192.0/24 (nats).

If all hosts are really in .192. and no other routes or L3 device exists just update that eth0 entry.

Making the next step: Confirm .0. is not typo and draw us the bigger picture, or stick an interface in .192. on the vyos box.

So one other tiny thing you might try since you have 192.168.0.1/24 (eth0) but different 192.168.192.0/24 (nats).

In T375#7874, @p10003 wrote:

Hey Rob,

Might be handy to post:
sh nat
sh system conntrack modules sip

sip
disable/enable-indirect-media/enable-indirect-signalling

Hey Rob,

we actually need clean up grup config a bit
as it have 2 timers for 5 seconds and it's kind of annoying

@syncer @dmbaturin @UnicronNL is there any reason to not implement this? I think this should be doable in less then two hours.

@kingrvbee this is not entirely correct. The problem comes from package vyos-1x which now holds the lldp configuration nodes. @dmbaturin is aware of this and wanted to fix it. Please be patient.

This patch something error

Here's the article: https://wiki.vyos.net/wiki/VyOS_on_GNS3

l# dpkg -l | grep snmpd
ii snmpd 5.7.2+vyos1+helium2 SNMP (Simple Network Management Protocol) agents

Any updates on this? I can't seem to win. On 1.1.7 snmp is broken due to my intel 10g nics and now on beta snmp works but netflow doesnt work :(

Please check with latest night build
Not likely that we will spend time on this in 1.1. x series

dpkg -l | grep snmpd and it says 5.7.2+vyos1+helium2 Which is what is already on /tmp/khagen/snmp .. I downloaded the packages and installed them but same issue with timeouts and high load on the system. 82599EB

Yes, @Tania and I are working on the rewrite.

Please also see T393

@mickvav Interesting Idea, I should give it a try ...

@Asteroza this program forwards UDP packets (Layer 3) on specific ports. Unfortunately WoL is Layer 2 based.

Just wondering, if it's possible to address this problem by just addint some firewall rule like
iptables -t mangle -j TEE ...
Did anyone did some digging into xtables-addons package to elaborate, whether it's possible to use firewall for this kind of things? I think, it should be much faster to do this things in kernel, than in userspace.

This could be possibly used for targeted Wake-on-LAN packet relaying as well...

Create a new repo (dev.packages.vyos.net/debian) and moved hvinfo to there.

https://github.com/vyos/vyos-1x/commit/ecdbe7b6fb64ae7d27d9147aa2c4a55b3a491735
https://github.com/vyos/vyos-1x/commit/5404d4108b510765150c2ac54098cd26ec18a683

The current implementation with postfix aliases is/was a bit problematic because all spam sent to it is forwarded to all members, and the mail servers where member addresses are get upset with mine and report me to spam lists.

I've merged the quagga pull request. Do you have implementation of the CLI for it, or shall I add it?

Created "current" and "helium" branches.

I can verify that it now also boots on OVH.net VPS.

@babak that would be awesome as I do not have any IPv6 BGP connectivity. I created a temporary SSH key for this, could you please create a user cpo:

I might be able to stand up a Vyos Instance with v6 BGP for you to test. Let me know when you are ready for it and I'll get it spun up.