Messages

... it still shows 16.1.8 as the last release and obviously 16.1.9 is out since a while and 16.1.10 shall come today ....

Is there now a different announcement instrument?

Looking forward to your reply

Br br

So ...

some progress here:

when adapting the parameter for the dhclient in /etc/dhcp/dhclient.conf to the value

Code Select Expand


send dhcp-lease-time 84000;


Then a lease is written after <=30min. to the unbound config dhcpleases.conf

In jessie, the default value for this is 3600 and the lease is then ignored by the python script. Obviously when the lease valid time is too short, then it is not forwarded to unbound.

Is there an option that

a) the transfer of leases can be made immediately
b) to make sure that lease transfers are working with the default values of different systems in the network

Can I configure this somewhere?

Looking forward to your reply

Br br

Hallo,

when starting a new XEN VM which obtain its IP Adress from the DHCP server of opnsense, I had to note that this lease is not forwarded to the unbound DNS resolver. Could somebody explain which lease types are forwarded and which not?

According to my understanding, opnsense DHCP server puts the leases in /var/var/dhcpd/var/db/dhcpd.leases. From there, the script /usr/local/opnsense/scripts/dns/unbound_dhcpd.py regularly checks and writes the leases in the unbound required format to /var/unbound/dhcpleases.conf. Then, they can be resolved with DNS requests.

Not clear is WHICH leases are written. I would expect that all leases which are active, have address and hostname and are not expired should be written. This seems to not to be the case:

Here 2 examples of my leases:

Code Select Expand


lease 192.168.1.213 {
  starts 6 2016/04/09 15:29:23;
  ends 0 2016/04/10 15:29:23;
  cltt 6 2016/04/09 15:29:23;
  binding state active;
  next binding state free;
  rewind binding state free;
  hardware ethernet 74:81:14:30:f9:7f;
  uid "\001t\201\0240\371\177";
  client-hostname "iPad";
}


is in the unbound file available as

Code Select Expand


local-data-ptr: "192.168.1.213 iPad.example.xx"
local-data: "iPad.example.xx IN A 192.168.1.213"


Consequently, a command

Code Select Expand


dig iPad
; <<>> DiG 9.9.5-9+deb8u6-Debian <<>> ipad.example.xx
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39695
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ipad.example.xx. IN A

;; ANSWER SECTION:
ipad.example.xx. 3600 IN A 192.168.1.213

;; Query time: 0 msec
;; SERVER: 192.168.1.254#53(192.168.1.254)
;; WHEN: Sat Apr 09 20:24:22 CEST 2016
;; MSG SIZE  rcvd: 76


leads to the desired result

A second lease

Code Select Expand


lease 192.168.1.206 {
  starts 6 2016/04/09 17:44:48;
  ends 6 2016/04/09 19:44:48;
  cltt 6 2016/04/09 17:44:48;
  binding state active;
  next binding state free;
  rewind binding state free;
  hardware ethernet 00:16:3e:ef:c2:0c;
  client-hostname "develop";
}


has not been transferred to unbound during its entire active time.

Is there a reason for that? Although not so familiar with python, I could not find any reason in the script, why this lease should not be transferred.

Any ideas?

Looking forward to your reply.

Br br

[in the dom0]

Hallo,

If your opnsense runs as a HVM Xen domU I would recommend to try this https://forum.pfsense.org/index.php?topic=85797.15. This worked for me.

In Short

• find out the id of your domU
• execute in the dom0 the command 'ethtool -K vif<your-opnsense-domU-Id>.0 tx off'

This needs to be done  after each reboot of opnsense. at least in my case i had full speed again

Br br

Hi there,

in 15.7.23, an error has been described in https://forum.opnsense.org/index.php?topic=1890.0, which has been fixed;

In 16.1.2, it is back again in a similar form: dhcp server page throws

Code Select Expand

57 Warning: Illegal string offset 'lan' in /usr/local/www/services_dhcpv6.php on line 58 Warning: Illegal string offset 'opt1' in /usr/local/www/services_dhcpv6.php on line 57 Warning: Illegal string offset 'opt1' in /usr/local/www/services_dhcpv6.php on line 58 Warning: Illegal string offset 'opt2' in /usr/local/www/services_dhcpv6.php on line 57 Warning: Illegal string offset 'opt2' in /usr/local/www/services_dhcpv6.php on line 58

Part of this information is hidden behind the top menu bar on the page, however its visible; (last time it was in line 432, now in line 57...)

BR br

[on the dom0 side]

Hello,

I have a question wrt the checkbox 'Disable Hardware CRC offloading' in System->Einstellungen->Network. CRC Hardware offloading is indeed a known issue with some NIC drivers when Freebsd runs as XEN HVM. The issue manifests in almost zero throughput through Opnsense from any other VM and dom0. I would have assumed that the idea behind setting this box should fix the known NIC driver problem

In the (new extended) documentation it is also recommended to tick the checkbox when installing Opnsense as a VM. At least for my native XEN installation,  this setting has no effect except a slightly higher CPU load, while traffic ist still almost none.

After a lot of forum research and experimenting around when installing opnsense, the break through came when  CRC offloading has been configured for the vif between dom0 and opnsense on the dom0 side in tx direction. If  CRC offloading is not configured for the direction, then only less then 1k bit throughput can be seen to any VM through Opnsense. Why is still not really clear to me ....

Im still looking for a concept that this setting is automatically done when opnsense is booting.  Up to now, I still have to launch an ethtool command manually on the dom0 side after each reboot

Does anybody has different experiences with a XEN installation for this or has solved the booting problem?

Looking forward to your reply.

Br br

Hallo,

ich hatte ein ähnliches Problem mit meiner xen domU opnsense (allerdings vanilla, ohne xenserver). Ich würde mal vermuten, dass es an dem bekannten tx checksum Thema liegt, wenn freebsd als HVM DomU in Xen läuft. Da gab es mal einen interessanten Artikel zu:https://forum.pfsense.org/index.php?topic=85797.15

In short sieht die Lösung wie folgt aus:
1.) identifiziere das vif Interface zwischen Dom0 und opnsense DomU: Dazu brauchst Du die domU ID der Opnsense, die du mit (ich glaube so heisst es auf dem xen server)

Code Select Expand


xe vm-list


rausbekommst.

2.) Dann in der Dom0 ausführen

Code Select Expand


sudo ethtool -K vif<ID der opnsense DomU>.0 tx off


Wäre die ID zB 12, dann wäre das Kommando

Code Select Expand


sudo ethtool -K vif12.0 tx off


und dann sollte es wieder schnell sein - so war's zumindest bei mir. Leider habe ich noch kein vif-hook script zum Laufen bekommen, das dieses Kommando automatisch bei jedem boot der opnsense ausführt  ???

Br br

Franco,

thanks for your answer - meanwhile I am a bit more progressed in the analysis.

No, there is no multicast flooding visible on the LAN. The problem lies obviously somewhere else:

When running the igmproxy in DEBUG mode, the mcast group for IPTV program at 239.35.10.4 (German ARD TV) is joined accurately

Code Select Expand


Current routing table (Insert Route):
-----------------------------------------------------
#0: Src: 0.0.0.0, Dst: 239.255.255.246, Age:1, St: I, OutVifs: 0x00000001
#1: Src: 0.0.0.0, Dst: 239.255.255.250, Age:2, St: I, OutVifs: 0x00000001
#2: Src: 0.0.0.0, Dst: 224.0.0.251, Age:2, St: I, OutVifs: 0x00000001
-----------------------------------------------------
RECV V2 member report   from 192.168.1.254   to 224.0.0.2
The IGMP message was from myself. Ignoring.
RECV V2 member report   from 192.168.1.191   to 239.35.10.4
Should insert group 239.35.10.4 (from: 192.168.1.191) to route table. Vif Ix : 0
No existing route for 239.35.10.4. Create new.
Found existing routes. Find insert location.
Inserting at beginning, before route 239.255.255.246
Inserted route table entry for 239.35.10.4 on VIF #0
Joining group 239.35.10.4 upstream on IF address 192.168.2.100
joinMcGroup: 239.35.10.4 on xn1


A few ms later, the stream source sends the route activation request and starts the stream:

Code Select Expand


Current routing table (Insert Route):
-----------------------------------------------------
#0: Src: 0.0.0.0, Dst: 239.35.10.4, Age:2, St: I, OutVifs: 0x00000001
#1: Src: 0.0.0.0, Dst: 239.255.255.246, Age:1, St: I, OutVifs: 0x00000001
#2: Src: 0.0.0.0, Dst: 239.255.255.250, Age:2, St: I, OutVifs: 0x00000001
#3: Src: 0.0.0.0, Dst: 224.0.0.251, Age:2, St: I, OutVifs: 0x00000001
-----------------------------------------------------
Route activate request from 193.158.35.251 to 239.35.10.4
Vif bits : 0x00000001
Setting TTL for Vif 0 to 1
Adding MFC: 193.158.35.251 -> 239.35.10.4, InpVIf: 1


130 sec later, the igmpproxy sends a membership query on the LAN side as it should:

Code Select Expand


Current routing table (Insert Route):
-----------------------------------------------------
#0: Src: 193.158.35.251, Dst: 239.35.10.4, Age:1, St: A, OutVifs: 0x00000001
#1: Src: 0.0.0.0, Dst: 239.255.255.246, Age:2, St: I, OutVifs: 0x00000001
#2: Src: 0.0.0.0, Dst: 239.255.255.250, Age:2, St: I, OutVifs: 0x00000001
#3: Src: 0.0.0.0, Dst: 224.0.0.251, Age:2, St: I, OutVifs: 0x00000001
-----------------------------------------------------
RECV V2 member report   from 192.168.1.191   to 239.35.10.4
Should insert group 239.35.10.4 (from: 192.168.1.191) to route table. Vif Ix : 0
Updated route entry for 239.35.10.4 on VIF #0
Vif bits : 0x00000001
Setting TTL for Vif 0 to 1
Adding MFC: 193.158.35.251 -> 239.35.10.4, InpVIf: 1


And here according to my understanding the misbehavior start (correct me if I'm wrong) :

Neither the aging counter is increased again to 2 NOR the positive report leads to a membership report on the WAN side to the next router (in this case the fritzbox, which by the way sends every 30-60 sec. an membership query from its end which is never answered for 239.35.10.4)

Code Select Expand


Current routing table (Insert Route):
-----------------------------------------------------
#0: Src: 193.158.35.251, Dst: 239.35.10.4, Age:2, St: A, OutVifs: 0x00000001
#1: Src: 0.0.0.0, Dst: 239.255.255.246, Age:2, St: I, OutVifs: 0x00000001
#2: Src: 0.0.0.0, Dst: 239.255.255.250, Age:2, St: I, OutVifs: 0x00000001
#3: Src: 0.0.0.0, Dst: 224.0.0.251, Age:1, St: I, OutVifs: 0x00000001
-----------------------------------------------------
About to call timeout 18 (#0)
About to call timeout 9 (#0)
SENT Membership query   from 192.168.1.254   to 224.0.0.1
Sent membership query from 192.168.1.254 to 224.0.0.1. Delay: 10
Created timeout 19 (#0) - delay 10 secs
(Id:19, Time:10)
Created timeout 20 (#1) - delay 115 secs
(Id:19, Time:10)
(Id:20, Time:115)
RECV Membership query   from 192.168.1.254   to 224.0.0.1
RECV V2 member report   from 192.168.1.191   to 239.35.10.4
Should insert group 239.35.10.4 (from: 192.168.1.191) to route table. Vif Ix : 0
Updated route entry for 239.35.10.4 on VIF #0
Vif bits : 0x00000001
Setting TTL for Vif 0 to 1
Adding MFC: 193.158.35.251 -> 239.35.10.4, InpVIf: 1

Consequently, the stream is stopped by the sender/the fritzbox then, as no prolongation of the stream is requested. I assume a correlation that the IPTV route is the only one where the originAddr field is >0 (see rttable.c, line 652). All other route entry lead to a reaction of opnsense when a query is sent on the WAN interface)

Interesting enough, this cycle ist restarted automatically every 15-30 min. You see then on the WAN side suddenly a new join request, no clue what triggers it (might be a timer or so).

As igmpproxy-0.1 is code from 2009 (although a bunch of patches are documented in git) and I read somewhere that igmpproxy is not cascading, it would be great to modernize it to

• full IGMPv3 implementation on the LAN side
• Enable cascading with standard configurations

Perhaps a worth feature request  ;). Alternatively it might be an option to consider mrouted as additional service in opnsense

Sorry for the long message, but the issue is somewhat more tricky ....

Br br

Thanks Franco,

Installation of 15.7.24 ran as smooth as always.... :) :) :) :) :)

I then immediately tested it indeed: However, I have to say that it is not fixed with the release:

Still when you add in the german language version in Dienste->dhcp->server for the LAN interface in the section 'Statische DHCP Zuweisung für dieses interface'  another entry, then you press the 'Speichern' button and then 'Änderungen übernehmen', the light blue bar with the 'Änderungen übernehme'n button appears again and again. Only reboot helps to make it disappear .... ::) :-\

Br br

Hello,

I am trying since a while to make my IPTV (Entertain from Deutsche Telekom) working with the VLC player with some Apple clients. While several articles show how to achieve this by directly connecting over a VDSL Modem and XXsense (eg https://blog.tausys.de/2014/10/16/telekom-iptv-mit-pfsense/), I have to rely my Internet connection on a Fritzbox for several reasons. Many others have given up here, however I feel still some hope to be pretty close to a solution ... :o

I notice now that the igmpproxy of opnsense seem to show a behavior which prevents a stable igmp stream for more than 2 minutes. After that, the stream freezes; about 5-8 min later, another 2 min of TV can be seen on the client until the same happens again.

On the LAN side, I see the expected multicast behavior:

Code Select Expand


192.168.x.254  opnsense -> 224.0.0.1:           Opnsense sends general IGMP Membership Query
192.168.x.22    client        -> 239.35.10.4:       Client sends membership report for group 239.35.10.4 (i.e. German 1st TV program)

As opnsense' igmpproxy is only supporting IGMP V2 on the LAN side, this look OK to me, and this sequence is repeated every 120 sec. This means, that the client is reporting every 2 min, that it still wants to belong to this igmp IPTV group. So far so good ....

The - according to my understanding - strange behavior happens on the WAN side of opnsense: As said, in my configuration, it is connected with a fritz box. I also read about the igmpproxy that on the WAN side, igmpproxy speaks IGMPv3 as also the fritzbox does. I also read that igmpproxy shall behave LIKE A CLIENT. What I see is:

Code Select Expand


192.168.y.1         fritzbox         -> 224.0.0.1: Fritzbox sends general igmp membership query
192.168.y.100     opnsense     -> 224.0.0.22: IGMPv3: opnsense sends a Membership Report/Leave group 239.35.10.4 (why????)
and immediately after
192.168.y.100     opnsense     -> 224.0.0.22: IGMPv3: opnsense sends a Membership Report/join group 239.35.10.4 (why????)

After that, it does only sporadically or even not at all answers on the general igmp queries from the fritzbox for the IPTV stream; naturally, after 2 min, the fritzbox disconnects the igmp Data stream (UDP) with the TV data and sends from its side a leave group.

At least to me this sounds like a reasonable explanation pattern for the seen behavior. Not understood is indeed, why the stream starts after 5-8 min again and why then suddenly the igmpproxy again sends a join request...What might trigger it?

I would have expected, that for EACH membership report for the IP TV channel on the LAN side, also a membership report is generated on the WAN side. Does anybody here has seen the described behavior? Is this something what could be corrected with a config modification?

My igmpproxy.conf look as follow

Code Select Expand



##------------------------------------------------------
## Enable Quickleave mode (Sends Leave instantly)
##------------------------------------------------------
quickleave
phyint xn1 upstream ratelimit 0 threshold 1
altnet 193.158.0.0/15
altnet 224.0.0.0/4

phyint xn0 downstream ratelimit 0 threshold 1
altnet 192.168.x.0/32

phyint xn2 disabled
phyint xn3 disabled



Looking forward to your reply
Br br

All,

I can only support phoenix' statement and give a big thank you to the Team for their dedication, responsiveness and support!

As being not in time for christmas  ;) ;)  then at least a happy new year and looking forward to all the releases to come!

BR br

Hallo together,

Could this be verified? Is there a fix in planning?

Thanks for your reply

BR Br

Hello together,

during systematically walking through all GUI pages of services and trying it out, another faulty behavior appeared on the service 'dhcp server' configuration page:

When you have made an addition or modification on the static mapping dhcp area at the bottom, you can store ist but then pressing the 'Änderungen übernehmen' button leads to the picture as shown in the screenshot below.

The 'Änderungen übernehmen' banner then is always there and even survives a log out/login and can only be made disappearing via reboot (at least so far ...)

Br br

Hallo,

thanks for the quick reply

however - in my installation, now it looks different, but still a warning:

Without the fix I get this:

Code Select Expand


Warning: Illegal string offset 'wan' in /usr/local/www/services_dhcpv6.php on line 462 Warning: Illegal string offset 'wan' in /usr/local/www/services_dhcpv6.php on line 463 Warning: Illegal string offset 'lan' in /usr/local/www/services_dhcpv6.php on line 462 Warning: Illegal string offset 'lan' in /usr/local/www/services_dhcpv6.php on line 463 Warning: Illegal string offset 'opt1' in /usr/local/www/services_dhcpv6.php on line 462 Warning: Illegal string offset 'opt1' in /usr/local/www/services_dhcpv6.php on line 463 Warning: Illegal string offset 'opt2' in /usr/local/www/services_dhcpv6.php on line 462 Warning: Illegal string offset 'opt2' in /usr/local/www/services_dhcpv6.php on line 463

With the fix in your link I get

Code Select Expand


Warning: Illegal string offset 'wan' in /usr/local/www/services_dhcpv6.php on line 462 Warning: Illegal string offset 'lan' in /usr/local/www/services_dhcpv6.php on line 462 Warning: Illegal string offset 'opt1' in /usr/local/www/services_dhcpv6.php on line 462 Warning: Illegal string offset 'opt2' in /usr/local/www/services_dhcpv6.php on line 462


Br br

Hallo,

since 15.7.20, I get the following warning message on the dhcpv6 which also did not disappear after upgrade to 15.7.22:

Code Select Expand


Warning: Illegal string offset 'wan' in /usr/local/www/services_dhcpv6.php on line 462 Warning: Illegal string offset 'wan' in /usr/local/www/services_dhcpv6.php on line 463 Warning: Illegal string offset 'lan' in /usr/local/www/services_dhcpv6.php on line 462 Warning: Illegal string offset 'lan' in /usr/local/www/services_dhcpv6.php on line 463 Warning: Illegal string offset 'opt1' in /usr/local/www/services_dhcpv6.php on line 462 Warning: Illegal string offset 'opt1' in /usr/local/www/services_dhcpv6.php on line 463 Warning: Illegal string offset 'opt2' in /usr/local/www/services_dhcpv6.php on line 462 Warning: Illegal string offset 'opt2' in /usr/local/www/services_dhcpv6.php on line 463


Is this anything critical or can be easily fixed?

Looking forward to your reply

BR br