Omission of interface device: BuG on generation of rules after TS wizard

[GUproBR]

8. HOWDY, Community!

I took a little time to report a bug that came to me today.
It omits the interface device name on (line 46 for me) of /tmp/rules.debug at the time of reloading filters. Could this lead to flaws for basic users's, since the filters don't load okay? You bet! Users are users and they use things, broken or not. They will just use PFsense with half-a-filters loaded. No way! Let's fix that. Instead of blah'z I'm going to look into the code, must be something very simple, and can be related to the ERR which gave me before, concerning percentages of traffic to shape – by the way, they we're least than 40%, opposite to the ERR msg which I kindly examined, ignored, and well, here I am.

If this is already known, good, let's fix it. Gonna learn some serious scripting, I hope, and nice tricks, so if this is already known, I'm going to try to fix it anyway and post here. Did not went to REDMINE yet to confirm things.

TKS

--Gustavo Loureiro Conte
Linux Specialist (DevOps/SysAdm)
https://gu.pro.br


[GUproBR]

Oh noes! this is much worse than I tought. Look what happens when I try to rerun the wizard. OUCH


[GUproBR]

Phew. Took me so long because I lost connection with internet provider, today things are creepy in connectivity…

Okey. After loading filters successfully, by removing TS, noticing things got a little strange, no wizard would ever run. decided to :

1. REboot to clear any temporary stuff that could possibily be hurting gnomes
2. Second problem still there ( More ifaces than connections etc)
3. so I did what I did as shown on the pic; made a bkp of my /tmp on /root and NUKED IT FOR GOOD
4. rebooted again

Checking my gateway cfg, HERE's the McCoy: two GWs pointing to same host at same iface; certainly thats the cause of the scripting problem. Now to try and fix, I ADDED A GATEWAY TO THE LAN NETWORK -- as picz show. Same issue with Traffic Shapper Wizard.

Now to get a little more hardcore, I grep'. YEs I 'grep. I 'grep and I 'grep and when I finally found the string 'There are less interfaces than number of connections!', I grep' a little more, as picz show.

This helped me give some ideas, as last pic shows lotsa different errors with smaller string 'less interfaces than', which not only grep's faster, it grep's more! LoL

Noticing the errors from wireless ifaces, I realized this could have something to do with cloned ifaces, wifi, I was experimenting with, earlier today.

YEAH! Just had to

1. double check GWs

2. noticed there was a bogus iface, she was kinda disabled, kinda deleted, perphaps it was on deletion of config iface that this all started, TKS it happened on Traffic Shapping cfg and not on production!!!!!!! :O I swear I did not do anything wrong ppl. We should look into the code someday.

3. So I reconfigured that phantom iface, put a GW for her to be proud of, and tried the TS script again. wheeee same problem. SO it had nothing to do with that, lets double check things agan.

4. Then I noticed I HAD the LAN GW already but it was listed NONE at the own iface config page -- attrib the gw to the network and . .., SAME PROBLEM.

5. Thats when ppl freak. I went and deleted all the ifaces, and inserted again, then rebooted. I hate to reboot dude. But hey, that requires a brute PHYSICAL CONTACT with the machine, or iLo, or something KvM.this is not a solution at all. And uptime of server goes zero nooooo way, lets fix that.

I propose to find where this problem begins at the first place, because doesnt seem to be the TS that makes it happen.
Then when the right question comes,
the solution will be already there.

Could not think of anything And I had to fix fast. It was a poor solution, I know. :(

now got it: problem went to >/dev/null ? - gone? . nope. a poor solution is poor because it makes you loose time and fixex nothing. TO FIX IS TO FIX at the root of the issue!!!!!!!

some more clues: Maybe a misconfigured IPSEC tunnel which I was working on before, could lead to bogus iface conditions on scripts?
Maybe the Wifi, which never worked at all (drivers? its Atheros onboard. I'm talking of a laptop here, ppl, not a XEON blaster stuff, which is common, for PFSense users, to make old hardware useful by using freesoftware instead of tossing it away at garbage.
other clues: The absence of IPv6 in my network. . .. okey lets look at the source.

and at the root of every ISSUE
there is THE SOURCE

whichi I found by myself with my GREPz wheee

/usr/local/www/wizards/traffic_shaper_wizard_dedicated.inc

function step2_stepbeforeformdisplay() {
        global $config, $pkg;
        global $stepid, $savemsg;

        $wans = 0;
        $lans = 0;
        $iflist = array();
        $iflisttmp = get_configured_interface_with_descr();
        foreach ($iflisttmp as $if => $ifdesc) {
                if (!is_altq_capable(get_real_interface($if)))
                        continue;
                if (interface_has_gateway($if) || interface_has_gatewayv6($if))
                        $wans++;
                else
                        $lans++;
                $iflist[$if] = $ifdesc;
        }
        $numberofconnections = intval($config['ezshaper']['step1']['numberofconnections']);
        if ($numberofconnections > ($wans < $lans ? $wans : $lans)) {
                $savemsg=gettext("There are less interfaces than number of connections!");
                $stepid--;
                return;
        }

        $cfgname = "traffic_shaper_wizard_dedicated.xml";

        $fields =& $pkg['step'][1]['fields']['field'];

So last pic shows the True, REAL McCoy at all: I believe problem lies in the "altq" capability check. Since I got another error about that, while discovering this problem, I sure tried and changed that line. Guess what?
problem solved for me. But I'm curious about the inner neons of this subject, It's a good start in learning the devel of such a great suite. TKS PPL!

Another TANGO DOWN (I will surely report if there is another issue after that dirty fix)

PLEASE LET ME KNOW IF IT IS A VALID FIX! Now that CLARO NET VIRTUA suxxor provider got me back, I'm going to try the rest of the wizard. . . . and will inform of any issue.

Bingo! (?)

PS: just changed "continue;" to "$lans++"; inside the if inside the loop. dunno the consequences.

–Gustavo L Conte
Linux Specialist ( SysAdm/DevOps )
https://gu.pro.br


[GUproBR]

PERPHAPS IT'S THE "ELSE" misleading the logic! A normal logic error:
the else is supposed to be "ELSE the first if" or else the last one? Because the compiler will only do the same stuff always. PS: perphaps the most elegant way of fix is to nest into blocks, but I need to know "something ELSE"

:O

cya guys

– Guzpido Krush

https://gu.pro.br


[GUproBR]

8. but is it the same issue? what happened?

[jimp]

The ue0 network interface is not capable of using ALTQ. If there is any bug, it would be that it ever let you use that in the traffic shaper. It's not clear how you managed to get it into that state to start with, but that is the source of your problems. It was omitted because it would generate a pf error trying to load a rule for an interface that isn't capable of using ALTQ.

Get rid of the USB NIC if you want to use traffic shaping.

[GUproBR]

TKS!!!!! now everything makes sense again  8)

[GUproBR]

Jimp,

besides not using a laptop hardware at all,
I'm currently finding pointers to what would be the best recommendations concerning that particular hardware tuning in general at pfSense/FreeBSD layer

about the ue0 iface => USB 2.0 10100M Ethernet Adaptor (:udav0)
I agree that was cheap, not a valid solution at all - not only because of lack altq capabilities,
I cannot even set basic capabilities of card, this is plain macarrone when u actually need a whole yakissoba (see pic) - I recommend everybody not to buy it on the store next door for $10 bucks and use a better solution. TKS for the tip.

Concerning the Ethernet - and keep in mind I'm currently limited to USB2.0 bottleneck and also onboard NIC is 10Mb/100Mb only, but that will change in ten days when ethernet will be Gb and USB will be 3.0 :D - - can anyone point me towards the best setup for NICs?

The axge driver provides support for USB Gigabit Ethernet adapters based on the ASIX Electronics AX88179 USB 3.0 and AX88178A USB 2.0 chipsets
I'm talking about that dude here: http://www.asix.com.tw/products.php?op=pItemdetail&PItemID=131;71;112

because might have local patches for the driver, maybe the driver backported to pfSense may require additional info so I need certification before spending more $bucks on USB to eth NICs. . . .. ….

should I go for it?