Messages

1

16.1 Legacy Series / Suricata and PF Interaction Clarification

« on: January 31, 2016, 04:39:58 am »

The current "IDS" package in OPNsense, (Suricata IDS) is fresh enough that I don't understand where the packets get filtered.

I'm curious about the interaction between the Suricata IDS, and PF, when using the package in "IPS" mode?

• Does PF filter the packet first, or does the IPS?
  
• Can the Suricata rules be picked up by PF rules, (particularly rules which redirect the packet in some way- not block or deny?)
  
• Is Suricata really best to stand alone, (perhaps as an inline transparent bridge?)
  

The idea of filtering packets based on various packet content matches is obviously quite a powerful tool, and I'd love to know where the edges are here in OPNsense!

2

16.1 Legacy Series / Suricata and Hardware Offload Clarification

« on: January 31, 2016, 04:30:56 am »

Dipping my toe in, content-based deny is quite sweet to see in action here!  The IPS feature is just plain awesome.  I've never used suricata before, so I've got a few questions about how it works on OPNsense before I dive into suricata itself.

Regarding hardware offloading, it's not entirely clear to me which offloading would affect which rulesets.  For example applied use, blocking Bittorrent on a network with rules concerning user-agent detection,

"ET P2P Bittorrent P2P Client User-Agent (Bittorrent/5.x.x)"
http://doc.emergingthreats.net/bin/view/Main/2006372

For matches like this based on packet conent, I'd love to know if the hardware offloading really gets in the way?

• - packet checksum offloading will obviously break packet known-signature rules, but would it affect content based rules?
  
• - TSO and LRO offloading obviously will obviously break packet signature and rules looking for specific packet fragmentation, but will they affect content rules?
  

The reason I'm asking here is that this new Suricata implementation opens up a whole new world of content-based packet filtering, and I'm looking to find the lines where it plays nicely with other features I care about, (hardware offloading becomes important to me on large and small networks alike!)

Excited to be using this now, and to see this feature set become more refined as more people use it!

3

Portuguese - Português / Re: Portugueses Translation?

« on: August 03, 2015, 09:47:12 am »

https://github.com/opnsense/core/pull/299

I don não falar português, mas aqui é o começo bootstrapped para BR PT, se isso ajuda você.

Boa sorte e divirta-se!

4

Japanese - 日本語 / First translation pass, 85% complete, need help!

« on: August 03, 2015, 09:41:37 am »

Based on the prior work of Chie Taguchi, JP is in the home stretch!

http://dotike.github.io/opnsense.core.ja_JP.UTF8/
https://github.com/opnsense/core/blob/b18c8589ede06ab850a5c768400e0939a0690dc4/lang/ja_JP.po

The JP project needs translator help to get it over the line!

5

Japanese - 日本語 / Re: Licence - ライセンス

« on: May 27, 2015, 06:28:45 pm »

Hi chol,

Sorry if I was confusing-

My intention is to clarify that the actual translation work is proceeding covered by the same 2-clause BSD license as OPNsense itself.  I am not referring to documentation in Japanese, but OPNsense itself.

Now that the work is underway, (and the English canonical source is settled), this is the translation work I'm referring to:
https://github.com/dotike/opnsense.core.ja_JP.UTF8/blob/master/src/share/locale/ja_JP/LC_MESSAGES/OPNsense.po

--
However, this forum appears to be *BSD licensed content- (footer below), I'm not sure about the doc wiki but I'm assuming it's roughly licensed for use in the same spirit as the code.

Best,
.ike

6

Japanese - 日本語 / Re: こんにちは！

« on: May 12, 2015, 05:23:18 am »

http://dotike.github.io/opnsense.core.ja_JP.UTF8/

7

Japanese - 日本語 / Re: こんにちは！

« on: May 12, 2015, 04:54:56 am »

https://github.com/opnsense/core/commit/f63e5fd7376289d4b4c9889357135c49f16ec67d

8

Portuguese - Português / Re: Portugueses Translation?

« on: May 12, 2015, 04:51:55 am »

Done!

https://github.com/opnsense/core/blob/master/src/share/locale/en_US/LC_MESSAGES/OPNsense.pot

Time to start a translation?!

Best,
.ike

9

Japanese - 日本語 / Re: Status: re-generating EN canonical .pot file

« on: May 12, 2015, 04:50:10 am »

Hi All,

Just a heads up, the EN canonical .pot file is completed, and the OPNsense team has built tooling around helping manage keeping it up to date!

https://github.com/opnsense/core/blob/master/src/share/locale/en_US/LC_MESSAGES/OPNsense.pot

Best,
.ike

10

Japanese - 日本語 / Re: Status: re-generating EN canonical .pot file

« on: April 18, 2015, 03:46:26 am »

こにちわ、

以下の機械翻訳を言い訳をしてください、

ちょうどヘッドアップ - 英語.POTファイル上の最初のパスが完了しました。
--
Just a heads up - The first pass on the English .pot file is complete.

https://github.com/opnsense/core/pull/144

Best,
.ike

11

Portuguese - Português / Re: Portugueses Translation?

« on: April 18, 2015, 03:44:00 am »

Hi All,

Por favor, desculpe a tradução automática seguinte,

Apenas um heads-up - A primeira passagem no arquivo do Inglês .pot está completa.
--
Just a heads up - The first pass on the English .pot file is complete.

https://github.com/opnsense/core/pull/144

Best,
.ike

12

15.1 Legacy Series / Re: Japanese and Translations for User Interface

« on: April 18, 2015, 03:39:53 am »

Hi Franco, All,

5860 English strings pulled from the OPNsense source,

https://github.com/opnsense/core/pull/144

Now I'm walking through changes made to the source in the last month, to apply the changes to the .pot.

I'd like to move the files to its proper target destination before merging them to avoid thousands of lines of movement in the history. I like both suggested directories. Since it's only for the GUI we can certainly get away with /usr/local/opnsense/locale.

Yiiiikes. I just submitted a PR to core, finally with the completed file.

I'll leave it to your best judgement if you want the file moved, I can certainly submit another PR.

Ike, do you have any generation tools/scripts that maybe need to go into tools.git or core.git to make it easier for others to work on translations as well?

Yikes- I'm afraid I don't.  All the stuff in my branch is hack-ish one-off awk/sed stuff, and far from complete or safe.  (I kept chipping away at edge cases in pulling the strings cleanly, until I had gotten the human-editing cleanup work down to something reasonable).

With that, I've got parsing tools, but they were just scaffolding.

--
One set of tools I will need to hack out soon: something to run via cron (or git push hooks), which can be used to notify translators of:
- changes to the source which did not make it into the canonical English .pot
  (a harder problem to do perfectly)
- lines in a respective language file which now differ from the English canonical file

Best,
.ike

13

Japanese - 日本語 / Re: Status: re-generating EN canonical .pot file

« on: April 12, 2015, 10:26:35 am »

Hi Isaac,

Quote from: dotike on Today at 02:36:48 AM

    - The branch I'm working from is now 28 days old, and I'll need to check the diff for any relevant changes to the translation file.
    (Incedentally, I found a number of odd gettext calls in the source which I'll address later)

I read about those in your commits. The gettext() usage is quite bizarre at times. If you can point me to the lines or add pull requests for those that'd be lovely.

Indeed- after this hurdle is past, I'll start doing them small and granular.
Watching yall' commit in the last month, I realized that I may be a bit premature submitting changes- since yall' are deleting/reworking bits, it'd be a shame for me to waste time cleaning up lines of code which will disappear.

Speaking of gettext, I was thinking we should maybe consider doing the "__()" trick consistently. For one "_()" is just easier on the eyes and the double underscore makes it possible to replace the translation function if we ever decide to switch to non-gettext variants. What do you think?

I'm not sure I know/understand that trick, what is it?  If it makes it easier to read or parse, I'm all for it.  I'd love to one day see something with less GNU take the place of gettext, but I'm totally not thinking about that right now.

The only thing I can say is that my experiences is that many hands may touch the code, so if it's not extremely clear what the convention is, it'll get botched.  (A knucklehead like myself can grep for all gettext calls and get 99% of the way there with what I'm doing, for example.)

Quote from: dotike on Today at 02:36:48 AM

    - After a lot of slogging through the source code, I could generate much of the English .pot file content in an automated manner.  Yet, as with problems like this, comprehensive parsers take far longer to write than just editing the file- there are so many edge cases for how the strings are handled in the codebase.

I'm all for ditching edge cases. Maybe we also need guidelines on what is translated and how dynamic strings and html are embedded (or not). A wiki page or README on this would certainly help to keep the English translations high in quality. I'm not a professional in that regard as well, so I believe that would be a chance to improve and share knowledge.

Certainly- I'm no I18N expert, but I think basic coding policies are always good.  But some of the trouble cases are so obvious, they merely require sane eyes to clean up.  For example, here's a fun one:

Code: [Select]

core:src/www/interfaces.php:2150
Frankly, as much as this line is freaky- with the age and number of hands that have been on this code- I'm surprised at it's quality.  I've unfortunately seen much much worse, professionally speaking.

I've got about 450 "bad" lines left in the EN .pot, (Stopping around line 6953 of 27061 tonight), which leaves me plenty of time to ponder some basic things to contribute to README/quickstart guidelines...  I'll try to keep some notes as I go.

Quote from: dotike on Today at 02:36:48 AM

    Expected outcome: when I'm done with this pass, a functional .en POT file will be ready to push upstream, and I'll submit a pull request as soon as that's ready.  Yet, there will be a few things still to do from there:

Looking forward to it.

You can bet your ass at this point I'm looking forward to finishing this file too

Quote from: dotike on Today at 02:36:48 AM

    - OPNsense core will want to maintain the English file, as the canonical base for all other languages
    - The gettext machinery will need to be hooked up in to make it all work

Agreed, we can definitely do that.

Sweet!
In the future, so you don't feel burdened- I (and I hope others), will certainly help to keep things up to date too.
I'm mostly focused on keeping track of Japanese as time moves on, but keeping track of the English file is of course fundamental to that effort.

But for now, so glad you guys are hacking on the important bits

/salute

14

Portuguese - Português / Portugueses Translation?

« on: April 12, 2015, 02:44:20 am »

Por favor, desculpe esta tradução automática:

Eu sei que há um número de pessoas Portugueses brasileiros que pode estar interessado em OPNsense em sua língua nativa.

Eu estou trabalhando atualmente na reconstrução do Inglês .pot / arquivo de tradução gettext, aqui:

https://github.com/dotike/opnsense.core.ja_JP.UTF8/blob/locale.EN.canonical/src/share/locale/en/LC_MESSAGES/OPNsense.pot

Ela pode servir como base para traduzir a interface do usuário OPNsense para qualquer idioma. Quando estiver completo, eu vou acompanhar esta discussão!

--
I know there are a number of Brazilian Portugese people who may be interested in OPNsense in their native language.

I am currently working on rebuilding the English .pot/gettext translation file, here:

https://github.com/dotike/opnsense.core.ja_JP.UTF8/blob/locale.EN.canonical/src/share/locale/en/LC_MESSAGES/OPNsense.pot

It can serve as the base for translating the OPNsense user interface into any language.  When it is complete, I'll follow up on this thread!

Best,
.ike

15

Japanese - 日本語 / Re: Status: re-generating EN canonical .pot file

« on: April 12, 2015, 02:38:33 am »

A quick followup, here's the English file I'm working on:

https://github.com/dotike/opnsense.core.ja_JP.UTF8/blob/locale.EN.canonical/src/share/locale/en/LC_MESSAGES/OPNsense.pot