Messages

I got a pretty simple reproducible case.

1) opnsense box is at 192.168.1.2

2) connected to a swtich, which holds a cisco voip phone with DHCP/IP set on the opnsense to always be 192.168.1.82

3) The cisco phone cannot make the vpn connection, unless an out-NAT rule is added, that is working fine.

4) upon ISP outage, the opnsense, re-establishes internet connection, HOWEVER, the cisco voip fails to re-connect/authenticate despite the fact that a) it was running days before that w/o any issues, and b) all network is restored to all other devices c) the outbound NAT rule is in place.

5) I've debugged that for few months, and narrowed the issue to the fact that the opnsense box (192.168.1.2) cannot PING the cisco phone 192.168.1.82, after such outage, despite the fact that OTHER machines on the same switch can ping the cisco's IP just fine, before, and after outage..  Also, the 192.168.1.82 IP is marked as allocated to the cisco phone, and 'arp' output on the opnsense and another random PC agree on the cisco's MAC address, e.g.  opnsense:

Code Select Expand

? (192.168.1.82) at 08:cc:68:xx:xx:xx on bridge0 expires in 1176 seconds [bridge]
?

From random PC that can ping it:

Code Select Expand

192.168.1.82          08-cc-68-xx-xx-xx     dynamic


6) The "workaround" of course is to reboot the cisco voip, and then it works fine, however, that was not the case with my prior (hiding: tomato) firmware..

Is there any chance someone can help debug this? why is the ping working for the random PC, yet it does not for the opnsense box, which i suspect is the reason for the failure of the cisco phone to build the vpn tunnel..

Appreciate any tips.
Stormy.

I think I got the same issue, and after some time, realized I was testing it incorrectly.

If testing from HOME/LAN and connecting to the External IP, then opnsense is smart enough to know that you are on the LAN (despite hitting the public IP), and it allows login.  Also, tested from phone, but did it via wifi, which also travels through the opnsense box, so it too allowed login to web ui.

Finally, tested with phone without wifi, on cellular network, and it does not allow login to web gui on WAN port.

Hopefully this helps another newbie :)

Stormy.

oh, turns out this "password" field is not really the freedns password.  it's the TOKEN, see:

https://forum.opnsense.org/index.php?topic=4374.0

so this is OK.

Only "room for improvement" is to add a "last successful update" field, b/c it's impossible to know when it was updated from the UI unless looking in the logs.

Ah, took a quick look at services_dyndns_edit.php, and noticed that to configure correctly:

hostname: enter host
username: blank
password: TOKEN from freedns

actually, it is in the HELP in the UI.. oh well, missed it :)

all is working fine now.

Using 17.1RC1, trying to setup freeDNS which I assume refers to: https://freedns.afraid.org/

entering some hostname and user/password getting these in system.log when forcing update:

Jan 30 12:10:44 OPNsense opnsense: /services_dyndns_edit.php: Dynamic DNS (myhost.mine.to): PAYLOAD: ERROR: Invalid update URL (2)
Jan 30 12:10:44 OPNsense opnsense: /services_dyndns_edit.php: Dynamic DNS (myhost.mine.to): (Unknown Response)

From my experience on tomato based firmwares, it is possible to enter only the system generated TOKEN (withOUT any user/password information), tried that instead of the hostname, and got same error with the token name in place of the hostname.

Thinking, ah, maybe it wants the full URL, so entered this url obtained from afraid.org:

http://freedns.afraid.org/dynamic/update.php?Long-uuid-token

and then got this from the UI:

"The following input errors were detected:
    The Hostname contains invalid characters"

going to Docs. no hits for freedns: https://docs.opnsense.org/search.html?q=freedns&check_keywords=yes&area=default

no hits for dyndns, or even.. dns??

docs w/o search, not much help there.

Has anyone configured freedns correctly on OPNSense 17.1rc1?

On Tomato/firmware (sorry for the comparison) one only needs to enter a TOKEN for freeDNS service (afraid.org), but in opnsense, it seems user & password are required..

Is that secure? I'm assuming you post the request as https..   

and to get token implemented, is that by opening a git issue? or some other way.

Highly useful if you need to reach your boxes remotely.

Stormy..

Was renaming the WAN interfaces's description in the UI, all of sudden noticed network is down.. looking at the console, see this crash, Fatal trap 12: page fault while in kernel mode
thread pid 12 tid 100005

more in the photos here: http://imgur.com/a/qJrSY

one has "ps" (showing pid 12) along with "bt" on same screen.

Stormy

I hope that is the real issue, still looking for others to confirm independently.. 

After re-imaging the box several times, into 16.7 and 17.1RC1, it kept reproducing, so this time reimaged, and changed NO option at all, just setup the pppoe. and it worked fine.

Went through list of things changed before, and one was the MAC on the pppoe port.

Added it to the WAN interface, and IMMEDIATELY (after apply changes in ui), the setup became unstable, with 2 mpd running, and internet lost and disconnected constantly.  Removed the MAC, apply, and it becomes stable again..

so, for now, do not setup MAC on the WAN interface if PPPOE is used.

Thanks to suggestions on the chat, modified this in intrefaces.inc:

Code Select Expand

    /* fire up mpd */
    // Killbypid("/var/run/" . escapeshellarg($ppp['type']) . "_{$interface}.pid", 'TERM', true);  // STORMY
    killbyname('mpd5');
    file_put_contents("/tmp/Sleeping_10", '');
    sleep(10);
    @unlink("/tmp/Sleeping_10");
    mwexec_bg("/usr/local/sbin/mpd5 -b -k -d /var/etc -f mpd_{$interface}.conf -p /var/run/" .
        escapeshellarg($ppp['type']) . "_{$interface}.pid -s ppp " . escapeshellarg($ppp['type']) . "client");


then ping shows connection is made each time, but mpd5 is getting a TERM signal:

Code Select Expand

ping: sendto: No route to host
ping: sendto: No route to host
ping: sendto: No route to host
ping: sendto: No route to host
64 bytes from 8.8.8.8: icmp_seq=13 ttl=41 time=85.545 ms
64 bytes from 8.8.8.8: icmp_seq=14 ttl=41 time=84.778 ms
64 bytes from 8.8.8.8: icmp_seq=15 ttl=41 time=85.314 ms
ping: sendto: No route to host
ping: sendto: No route to host
ping: sendto: No route to host
ping: sendto: No route to host
ping: sendto: No route to host
ping: sendto: No route to host
ping: sendto: No route to host
ping: sendto: No route to host
ping: sendto: No route to host
ping: sendto: No route to host
ping: sendto: No route to host
ping: sendto: No route to host
ping: sendto: No route to host
64 bytes from 8.8.8.8: icmp_seq=29 ttl=41 time=87.857 ms
64 bytes from 8.8.8.8: icmp_seq=30 ttl=41 time=87.662 ms
64 bytes from 8.8.8.8: icmp_seq=31 ttl=41 time=87.687 ms
ping: sendto: No route to host
ping: sendto: No route to host
ping: sendto: No route to hos

Using the kill by pid (first line above), and the issue is worse:

running this monitor loop:

Code Select Expand

#!/bin/csh
while ( 0 < 1 )
  ls -l /tmp/Sleep*
  ps aux |grep mpd5|grep -v grep
  sleep 1
end


output when running:

Code Select Expand


root@OPNsense:/tmp # ./mon.sh
ls: No match.
ls: No match.
ls: No match.
ls: No match.
ls: No match.
ls: No match.
ls: No match.
ls: No match.
ls: No match.
-rw-r--r--  1 root  wheel  0 Jan 25 11:11 /tmp/Sleeping_10
-rw-r--r--  1 root  wheel  0 Jan 25 11:11 /tmp/Sleeping_10
-rw-r--r--  1 root  wheel  0 Jan 25 11:11 /tmp/Sleeping_10
-rw-r--r--  1 root  wheel  0 Jan 25 11:11 /tmp/Sleeping_10
-rw-r--r--  1 root  wheel  0 Jan 25 11:11 /tmp/Sleeping_10
-rw-r--r--  1 root  wheel  0 Jan 25 11:11 /tmp/Sleeping_10
-rw-r--r--  1 root  wheel  0 Jan 25 11:11 /tmp/Sleeping_10
-rw-r--r--  1 root  wheel  0 Jan 25 11:11 /tmp/Sleeping_10
-rw-r--r--  1 root  wheel  0 Jan 25 11:11 /tmp/Sleeping_10
ls: No match.
root   66845   0.0  0.1  44872  6076  -  Ss   11:11    0:00.00 /usr/local/sbin/mpd5 -b -k -d /var/etc -f mpd_wan.conf -p /var/
ls: No match.
root   66845   0.0  0.1  44872  6616  -  Ss   11:11    0:00.00 /usr/local/sbin/mpd5 -b -k -d /var/etc -f mpd_wan.conf -p /var/
ls: No match.
root   66845   0.0  0.1  44872  6616  -  Ss   11:11    0:00.00 /usr/local/sbin/mpd5 -b -k -d /var/etc -f mpd_wan.conf -p /var/
ls: No match.
root   60752   0.0  0.1  42692  5144  -  Ss   11:11    0:00.00 /usr/local/sbin/mpd5 -b -k -d /var/etc -f mpd_wan.conf -p /var/
root   66845   0.0  0.1  44872  6624  -  Ss   11:11    0:00.01 /usr/local/sbin/mpd5 -b -k -d /var/etc -f mpd_wan.conf -p /var/
ls: No match.
root   60752   0.0  0.1  42692  5144  -  Ss   11:11    0:00.00 /usr/local/sbin/mpd5 -b -k -d /var/etc -f mpd_wan.conf -p /var/
root   66845   0.0  0.1  44872  6624  -  Ss   11:11    0:00.01 /usr/local/sbin/mpd5 -b -k -d /var/etc -f mpd_wan.conf -p /var/
ls: No match.
root   60752   0.0  0.1  42692  5144  -  Ss   11:11    0:00.00 /usr/local/sbin/mpd5 -b -k -d /var/etc -f mpd_wan.conf -p /var/
-rw-r-----  1 root  wheel  0 Jan 25 11:12 /tmp/Sleeping_10
root   60752   0.0  0.1  44872  6072  -  Ss   11:11    0:00.00 /usr/local/sbin/mpd5 -b -k -d /var/etc -f mpd_wan.conf -p /var/
-rw-r-----  1 root  wheel  0 Jan 25 11:12 /tmp/Sleeping_10
root   60752   0.0  0.1  44872  6072  -  Ss   11:11    0:00.00 /usr/local/sbin/mpd5 -b -k -d /var/etc -f mpd_wan.conf -p /var/
-rw-r-----  1 root  wheel  0 Jan 25 11:12 /tmp/Sleeping_10
root   60752   0.0  0.1  44872  6072  -  Ss   11:11    0:00.00 /usr/local/sbin/mpd5 -b -k -d /var/etc -f mpd_wan.conf -p /var/
-rw-r-----  1 root  wheel  0 Jan 25 11:12 /tmp/Sleeping_10
root   60752   0.0  0.1  44872  6612  -  Ss   11:11    0:00.01 /usr/local/sbin/mpd5 -b -k -d /var/etc -f mpd_wan.conf -p /var/
-rw-r-----  1 root  wheel  0 Jan 25 11:12 /tmp/Sleeping_10
root   60752   0.0  0.1  44872  6612  -  Ss   11:11    0:00.01 /usr/local/sbin/mpd5 -b -k -d /var/etc -f mpd_wan.conf -p /var/
-rw-r-----  1 root  wheel  0 Jan 25 11:12 /tmp/Sleeping_10
root   60752   0.0  0.1  44872  6612  -  Ss   11:11    0:00.01 /usr/local/sbin/mpd5 -b -k -d /var/etc -f mpd_wan.conf -p /var/
-rw-r-----  1 root  wheel  0 Jan 25 11:12 /tmp/Sleeping_10
root   60752   0.0  0.1  44872  6612  -  Ss   11:11    0:00.01 /usr/local/sbin/mpd5 -b -k -d /var/etc -f mpd_wan.conf -p /var/


clearly showing TWO mpd5 running, as well as a running process yet the Sleeping_10 file is there? how is this possible??

Only thing that amazes me, how come I'm the only one who hits this ??

[TERM signal]

Sorry for the long post..

Here is more info, pretty much at a loss here..  This is client/PPPOE, it should work, have no clue what's going on here...   

Update thus far:

1) Same behavior in 16.7/17.1
2) Replaced CAT5 cable, same behavior of constant disconnection if UI is used to initiate the pppoe connection.

3) Get this! 
   - disable mpd5 in /usr/local/etc/inc/interfaces.inc  on line #1593 prevents UI from starting pppoe
   - REBOOT. so, no pppoe is started (expected on purpose)
   - run it MANUALLY, using mpd.sh which has:

/usr/local/sbin/mpd5 -k -d /var/etc -f mpd_wan.conf -p /var/run/pppoe_wan.pid -s ppp pppoeclient

connection is made *instantly*, output to screen appears as follows:

Code Select Expand

[wan] IPCP: rec'd Configure Nak #2 (Req-Sent)
[wan]   IPADDR x.y.z.x
[wan]     x.y.z.x is OK
[wan] IPCP: SendConfigReq #3
[wan]   IPADDR x.y.z.x
[wan] IPCP: rec'd Configure Ack #3 (Req-Sent)
[wan]   IPADDR x.y.z.x
[wan] IPCP: state change Req-Sent --> Ack-Rcvd
[wan] IPCP: rec'd Configure Request #52 (Ack-Rcvd)
[wan]   IPADDR a.b.c.d
[wan]     a.b.c.dis OK
[wan] IPCP: SendConfigAck #52
[wan]   IPADDR a.b.c.d
[wan] IPCP: state change Ack-Rcvd --> Opened
[wan] IPCP: LayerUp
[wan]   x.y.z.x -> a.b.c.d
[wan] IFACE: Up event
[wan] IFACE: Rename interface ng0 to pppoe1


a.b.c.d is isp assigned IP, and x.y.z.x is ISPGW.  the last line remains as-is, and nothing is further outputed, the connection can run like that for hours, no failures, no disconnections.

In addition, press ctrl-C, connection is terminated, now, re-run the mpd.sh, and connection is re-established instantly, with different IP.. again, last line is the "Rename interface..."

4) Re-ran the same test as #3 again with mpd5 disabled in interfaces.inc, and added the "-b" flag, to run cmd in background, and still there is success in repeated tests, no matter how many times I pkill mpd5 and re-run, the connection to ISP is made instantly, ip assigned and internet is working fine.

5) now.. comes the bad news :)

pkill all manually mpd5 processes, restore original interfaces.inc, with pppoe enabled, and REBOOT.

Connection to ISP is established with valid IP.

Now, go to UI, and press the "disconnect" button..

From that point on, there is NO WAY to make another pppoe connection, be it manual or via GUI.. the only thing that fixes it is REBOOTING the box again. 

In some cases, ps output showed TWO mpd5 processes, with parent pid of 1. for example:

Code Select Expand

root@OPNsense:/usr/local/etc/inc # ps xao pid,ppid,sid,comm | grep mpd
34498     1 34498 mpd5
40616     1 40616 mpd5


Maybe UI is restarting them or killing them too frequently?  when the UI runs mpd5 the pings on the interface go up to 2-3 SECONDS, as soon as it is stopped, they drop to 0.2 second:

Code Select Expand

64 bytes from 11.0.0.11: icmp_seq=45 ttl=64 time=4258.030 ms
64 bytes from 11.0.0.11: icmp_seq=47 ttl=64 time=2140.550 ms
64 bytes from 11.0.0.11: icmp_seq=48 ttl=64 time=1116.655 ms
64 bytes from 11.0.0.11: icmp_seq=49 ttl=64 time=0.493 ms
64 bytes from 11.0.0.11: icmp_seq=50 ttl=64 time=4360.046 ms
64 bytes from 11.0.0.11: icmp_seq=51 ttl=64 time=3348.250 ms
64 bytes from 11.0.0.11: icmp_seq=52 ttl=64 time=2333.019 ms
64 bytes from 11.0.0.11: icmp_seq=53 ttl=64 time=1303.352 ms
64 bytes from 11.0.0.11: icmp_seq=55 ttl=64 time=0.207 ms
64 bytes from 11.0.0.11: icmp_seq=56 ttl=64 time=0.262 ms
64 bytes from 11.0.0.11: icmp_seq=57 ttl=64 time=0.205 ms
64 bytes from 11.0.0.11: icmp_seq=58 ttl=64 time=0.286 ms
64 bytes from 11.0.0.11: icmp_seq=59 ttl=64 time=0.268 ms
64 bytes from 11.0.0.11: icmp_seq=60 ttl=64 time=0.173 ms


also, ps output shows pid of mpd5 changes very fast as it fails or gets a TERM signal.

6) Once this state is arrived, without a reboot, go and disable pppoe in interfaces.inc, made sure no mpd5 are lingering, now, ran the mpd5 manually, and pppoe connection shows as ESTABLISHED, an IP is given by the ISP, but for some reason, mpd5 is getting a TERM signal and all goes downhill:

notice the caught fatal signal TERM line in output below:

Code Select Expand

[wan] IPCP: rec'd Configure Ack #3 (Req-Sent)
[wan]   IPADDR v.x.y.z
[wan] IPCP: state change Req-Sent --> Ack-Rcvd
[wan] IPCP: rec'd Configure Request #83 (Ack-Rcvd)
[wan]   IPADDR a.b.c.d
[wan]     a.b.c.d is OK
[wan] IPCP: SendConfigAck #83
[wan]   IPADDR a.b.c.d
[wan] IPCP: state change Ack-Rcvd --> Opened
[wan] IPCP: LayerUp
[wan]   v.x.y.z -> a.b.c.d
[wan] IFACE: Up event
[wan] IFACE: Rename interface ng0 to pppoe1
[b]caught fatal signal TERM[/b]
[wan] IFACE: Close event
[wan] IPCP: Close event
[wan] IPCP: state change Opened --> Closing
[wan] IPCP: SendTerminateReq #4
[wan] IPCP: LayerDown
[wan] IFACE: Down event
[wan] IFACE: Rename interface pppoe1 to pppoe1
[wan] IPV6CP: Close event
[wan] IPV6CP: state change Stopped --> Closed
[wan] IPCP: rec'd Terminate Ack #4 (Closing)
[wan] IPCP: state change Closing --> Closed
[wan] IPCP: LayerFinish
[wan] Bundle: No NCPs left. Closing links...
[wan] Bundle: closing link "wan_link0"...
[wan_link0] LCP: rec'd Terminate Request #121 (Opened)
[wan_link0] LCP: state change Opened --> Stopping
[wan_link0] Link: Leave bundle "wan"


ran the same thing with ktrace, here is the ktrace output showing that SIGTERM:

Code Select Expand

       "<30>Jan 24 22:21:35 ppp: [wan_link0] LCP: LayerUp"
27970 mpd5     RET   sendto 49/0x31
27970 mpd5     CALL  write(0x1,0x487dc44c000,0x1a)
27970 mpd5     GIO   fd 1 wrote 26 bytes
       "[wan_link0] LCP: LayerUp\r
       "
27970 mpd5     RET   write 26/0x1a
27970 mpd5     CALL  recvfrom(0x8,0x487dc66110e,0x10fa,0x80<MSG_DONTWAIT>,0x6dc102a4be10,0x6dc102a4be0c)
27970 mpd5     RET   recvfrom -1 errno 35 Resource temporarily unavailable
27970 mpd5     CALL  read(0x3,0x2ccec46ff70,0x1)
27970 mpd5     GIO   fd 3 read 1 byte
       "\0"
27970 mpd5     RET   read 1
27970 mpd5     CALL  poll(0x487dc60e008,0xa,0x7d0)
27970 mpd5     RET   poll -1 errno 4 Interrupted system call
27970 mpd5     PSIG  SIGTERM caught handler=0x487db67dc60 mask=0x0 code=SI_USER
27970 mpd5     CALL  sigprocmask(SIG_SETMASK,0x6dc102a4b9e4,0)
27970 mpd5     RET   sigprocmask 0
27970 mpd5     CALL  write(0xe,0x6dc102a4b5dc,0x1)
27970 mpd5     GIO   fd 14 wrote 1 byte
       0x0000 0f                                                                          |.|

27970 mpd5     RET   write 1
27970 mpd5     CALL  sigreturn(0x6dc102a4b610)
27970 mpd5     RET   sigreturn JUSTRETURN
27970 mpd5     CALL  poll(0x487dc60e008,0xa,0x793)
27970 mpd5     RET   poll 1
27970 mpd5     CALL  write(0x4,0x2ccec46ff70,0x1)
27970 mpd5     GIO   fd 4 wrote 1 byte
       "\0"
27970 mpd5     RET   write 1
27970 mpd5     CALL  read(0xd,0x6dc102a4be37,0x1)
27970 mpd5     GIO   fd 13 read 1 byte
       0x0000 0f                                                                          |.|

27970 mpd5     RET   read 1
27970 mpd5     CALL  sendto(0x5,0x6dc102a4ac70,0x31,0,0,0)
27970 mpd5     GIO   fd 5 wrote 49 bytes
       "<30>Jan 24 22:21:35 ppp: caught fatal signal TERM"
27970 mpd5     RET   sendto 49/0x31
27970 mpd5     CALL  write(0x1,0x487dc44c000,0x1a)
27970 mpd5     GIO   fd 1 wrote 26 bytes
       "caught fatal signal TERM\r
       "
27970 mpd5     RET   write 26/0x1a
27970 mpd5     CALL  sigprocmask(SIG_SETMASK,0x487db686bb0,0x6dc102a4b9a8)
27970 mpd5     RET   sigprocmask 0

From this point on, there is no way to re-establish a pppoe, and a reboot resolves it.

To summarize:

1) PPPOE always works after a fresh reboot.

2) If UI is used to disconnect/reconnect, or cable is pulled or any other of network outage, and opnsense/UI restarts the pppoe, then it gets into a wedged state, and constantly forks mpd5 processes, only way out of it is a REBOOT.

3) If mpd5 is disabled in interfaces.inc, then mpd5 can run manually as many times as desired, and connects just fine, gets IP and internet is working, press ctrl-c as many times, and re-start manually all connects OK.

Any ideas welcomed.

Stormy.

Looking at the log inside the ADSL modem it shows that link goes UP/DOWN constantly, like so:

Code Select Expand

Jan  2 04:04:17 (none) daemon.crit kernel: eth2 Link UP 100 mbps full duplex  82
Jan  2 04:04:17 (none) daemon.info kernel: br0: port 3(eth2) entering forwarding state  92
Jan  2 04:04:21 (none) daemon.crit kernel: eth2 Link DOWN.  64
Jan  2 04:04:21 (none) daemon.info kernel: br0: port 3(eth2) entering disabled state  90
Jan  2 04:04:23 (none) daemon.crit kernel: eth2 Link UP 100 mbps full duplex  82
Jan  2 04:04:23 (none) daemon.info kernel: br0: port 3(eth2) entering forwarding state  92
Jan  2 04:04:27 (none) daemon.crit kernel: eth2 Link DOWN.  64
Jan  2 04:04:27 (none) daemon.info kernel: br0: port 3(eth2) entering disabled state  90
Jan  2 04:04:28 (none) daemon.crit kernel: eth2 Link UP 100 mbps full duplex  82
Jan  2 04:04:28 (none) daemon.info kernel: br0: port 3(eth2) entering forwarding state  92
Jan  2 04:04:32 (none) daemon.crit kernel: eth2 Link DOWN.  64
Jan  2 04:04:32 (none) daemon.info kernel: br0: port 3(eth2) entering disabled state  90
Jan  2 04:04:34 (none) daemon.crit kernel: eth2 Link UP 100 mbps full duplex  82
Jan  2 04:04:34 (none) daemon.info kernel: br0: port 3(eth2) entering forwarding state  92


Looking at the LEDs that is also confirmed, and also from ifconfig on the OPNS box:

one second the link appears like so:

Code Select Expand

igb3: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=4400b8<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWTSO,TXCSUM_IPV6>
        ether 00:xx:yy:zz:aa:bb
        inet6 fe80::21a:70ff:fee1:d41a%igb3 prefixlen 64 scopeid 0x4
        inet 11.0.0.12 netmask 0xffffff00 broadcast 11.0.0.255
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
        media: Ethernet 100baseTX <full-duplex> (autoselect)
        status: no carrier


and the next second it is active:

Code Select Expand

igb3: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=4400b8<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWTSO,TXCSUM_IPV6>
        ether 00:xx:yy:zz:aa:bb
        inet6 fe80::21a:70ff:fee1:d41a%igb3 prefixlen 64 scopeid 0x4
        inet 11.0.0.12 netmask 0xffffff00 broadcast 11.0.0.255
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
        media: Ethernet 100baseTX <full-duplex>
        status: active


is this normal? or a side-effect of the pppoe failing?

also, i've tried setting speed/duplex to auto or to 100Full as that's what the adsl modem can do.

Thanks for any ideas.

Thanks to solution from: https://forum.opnsense.org/index.php?topic=4334.0

managed to boot into 16.7, and pppoe has the exact same behavior there, it works only for the FIRST boot, thereafter, clicking the disconnect button (under interfaces/overview), OR pulling cable for 10sec causes the pppoe to go into an endless loop attempting to connect, and it can run like that for hours on end..

Using the exact same ADSL modem, and cable, i got 4 linksys running tomato/shibby/ddwrt, and the exact same CAT5 wire connected to these connects fine to pppoe using same ISP/credentials, and can disconnect and reconnect 4 times a minute without any issues, all works very fast and easy...

no clue how to debug such a thing..  but, it is not 17.1 related, something specific to my env i guess .. :(

This is x64.. 

First time someone hit this?? that may not a good sign :) :)

Seems like a pretty basic and useful thing, to be able to boot multiple versions w/o wiping the box :) testing/qa/perf comparisons :)

I'm new to freebsd (from linux, no /proc/partitions, etc.), so here it is for the benefit of others who were as clueless as I was :)

16.7 fstab:

Code Select Expand

root@OPNsense:/mnt/etc # cat fstab
# Device                Mountpoint      FStype  Options         Dump    Pass#
/dev/gpt/rootfs /               ufs     rw,noatime      1       1


and, by comparison, this is the 17.1:

Code Select Expand

root@OPNsense:/mnt/etc # cat /etc/fstab
# Device                Mountpoint      FStype  Options         Dump    Pass#
/dev/gpt/rootfs /               ufs     rw              1       1
/dev/gpt/swapfs         none            swap    sw              0       0


so, the "label" is that "/dev/gpt/rootfs", and the fix was "simply" to replace that on the USB with the specific uuid for that USB, e.g.

Code Select Expand

root@OPNsense:~ # cat /etc/fstab
# Device                Mountpoint      FStype  Options         Dump    Pass#
/dev/gptid/9088a5eb-e1ba-11e6-a89f-000ec4cf493f /               ufs     rw,noatime      1       1


now, can easily boot multiple versions on the same box.

Thanks Franco!

I was running into several issues on 17.1RC1, and wanted to test on 16.7, so kept re-imaging, but that got tired after the 3rd time :) :)  Since I got one box, thought how to run them "in dual boot".

My box has a builtin SSD (128GB) with 17.1 now installed, and there is no way to install on a partition is my understanding.

Folks suggested to install the 16.7 on a USB stick, so took a 32GB and installed, but, during boot, the menu clearly shows version 16.7, i.e. from the USB, then selecting "1", and it boots, but eventually I get into the 17.1 login prompt.. There is no crash or restart, and I'm pretty certain I did install the 16.7 into that USB stick, otherwise how would it show that 16.7 boot prompt :)

running "df" and all shows as if it's the 17.1rc1...

not sure why that is the case, and how to simply run both in dual mode, appreciate any experiences from others.
Stormy./