with https://repo.turris.cz/omnia-hbk/medkit/omnia-medkit-latest.tar.gz dated 2018-11-08
PPoE WAN connectivity is not working. Whilst the physical link is reportedly the log does not show the PPoE module being loaded.
Try this link … there is the newest version from 2018-12-05
I found the PPoE modules being present and loaded. It seems that the physical is instead not getting established.
Just tried the build from today https://repo.turris.cz/hbd/medkit/omnia-medkit-latest.tar.gz and the wan pppoe is not getting connectivity. The medkit with 32 MB in size, and thus much smaller in comparison to current stable 50M, is perhaps not yet not loaded with all the necessary drivers for User experience - ALLNET ALL4781-VDSL2-SFP / Switch Modul (Mini-GBIC), VDSL2
Given it another shot with today’s HBD automated build but still no luck with PPPoE connectivity 
turris pppd[20344]: RP-PPPoE plugin version 3.8p compiled against pppd 2.4.7
turris pppd[20344]: pppd 2.4.7 started by root, uid 0
turris pppd[20344]: Timeout waiting for PADO packets
turris pppd[20344]: Unable to complete PPPoE Discovery
turris pppd[20344]: Exit.
Without inet connectivity the Foris wizard crashes at some point.
Some other observations
leak
Summary
mv88e6085 f1072004.mdio-mii:10: switch 0x1760 detected: Marvell 88E6176, revision 1
libphy: mv88e6xxx SMI: probed
------------[ cut here ]------------
WARNING: CPU: 0 PID: 1 at fs/proc/generic.c:572 remove_proc_entry+0x140/0x154
remove_proc_entry: removing non-empty directory ‘irq/58’, leaking at least ‘mv88e6xxx-g2’
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.14.90 #0
Hardware name: Marvell Armada 380/385 (Device Tree)
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0x88/0x9c)
[] (dump_stack) from [] (__warn+0xe4/0x100)
[] (__warn) from [] (warn_slowpath_fmt+0x38/0x48)
[] (warn_slowpath_fmt) from [] (remove_proc_entry+0x140/0x154)
[] (remove_proc_entry) from [] (unregister_irq_proc+0xcc/0xe8)
[] (unregister_irq_proc) from [] (free_desc+0x2c/0x54)
[] (free_desc) from [] (irq_free_descs+0x40/0x74)
[] (irq_free_descs) from [] (mv88e6xxx_g1_irq_free_common+0x4c/0x74)
[] (mv88e6xxx_g1_irq_free_common) from [] (mv88e6xxx_irq_poll_free+0x2c/0x38)
[] (mv88e6xxx_irq_poll_free) from [] (mv88e6xxx_probe+0x318/0x344)
[] (mv88e6xxx_probe) from [] (really_probe+0x114/0x274)
[] (really_probe) from [] (bus_for_each_drv+0x44/0x98)
[] (bus_for_each_drv) from [] (__device_attach+0x78/0xe0)
[] (__device_attach) from [] (bus_probe_device+0x28/0x88)
[] (bus_probe_device) from [] (device_add+0x3d0/0x5b4)
[] (device_add) from [] (mdio_device_register+0x1c/0x44)
[] (mdio_device_register) from [] (of_mdiobus_register+0x168/0x2b4)
[] (of_mdiobus_register) from [] (orion_mdio_probe+0x204/0x2e8)
[] (orion_mdio_probe) from [] (platform_drv_probe+0x34/0x70)
[] (platform_drv_probe) from [] (really_probe+0x114/0x274)
[] (really_probe) from [] (__driver_attach+0x8c/0xb0)
[] (__driver_attach) from [] (bus_for_each_dev+0x4c/0xa0)
[] (bus_for_each_dev) from [] (bus_add_driver+0xe8/0x200)
[] (bus_add_driver) from [] (driver_register+0xa8/0xe4)
[] (driver_register) from [] (do_one_initcall+0xc0/0x184)
[] (do_one_initcall) from [] (kernel_init_freeable+0x1c0/0x254)
[] (kernel_init_freeable) from [] (kernel_init+0x8/0x114)
[] (kernel_init) from [] (ret_from_fork+0x14/0x2c)
—[ end trace 8987b9cf2ea8acbd ]—
some weird watchdog stuff
Summary
watchdog: watchdog0: nowayout prevents watchdog being stopped!
watchdog: watchdog0: watchdog did not stop!
watchdog: watchdog0: nowayout prevents watchdog being stopped!
watchdog: watchdog0: watchdog did not stop!
and then some
(NULL device *): hwmon_device_register() is deprecated. Please convert the driver to use hwmon_device_register_with_info().
bridge: filtering via arp/ip/ip6tables is no longer available by default. Update your scripts to load br_netfilter if you need this.
urandom-seed: Seed file not found (/etc/urandom.seed)
2 weeks later and 1 months from the initial test there appears little progress for the Omnia, the only notable perhaps Foris not crashing.
Forward another 2.5 weeks and no development for the Omnia to report.
Wondering whether PPPoE WAN is even working on the MOX.
After the TOS cleanup branch been merged into master I thought to give another go with https://repo.turris.cz/☞🐉/medkit/omnia-medkit-latest.tar.gz 2019-02-17 04:51 but unfortunately it seems that things have regressed as now the router clients are not getting any dhcp address and thus 192.168.1.1 cannot be reached.
I am not going to dig out the UART and start dissembling the TO for further investigation.
Just small note: stuff changed and medkits are now in default configured to point to hbs not source branch. Using hbd medkit and enabling updater causes system to downgrade to hbs. To prevent that you have to do switch-branch hbd before updater is enabled.
1 Like
@cynerd - about PPPoE
The difference then perhaps is down to the modem in the non-working SFP port - my end being User experience - ALLNET ALL4781-VDSL2-SFP / Switch Modul (Mini-GBIC), VDSL2 - Omnia HW tweaks - Turris forum which works fine in current TOS3.x however
I am not sure whether they are testing medkit installations on a daily basis but DHCP assignment is not working my end with HBD at the moment. It used to be working previously and it does with alpha2 HBS but since then there seems to be regression with the HBD medkit.
No, medkits are not tested on daily bases for hbd. I don’t see how that could happen. Are you talking about ipv4 or ipv6? Are you talking about lan (assignment to clients) or about wan (assignment to router)? How did you figure that out? Have you assigned static ip to your pc and connected to system? Can you debug problem?
No, because SFP/PPPoE is not working and thus not applicable as the vdsl modem is inserted in the SFP port.
Both.
Yes, set gateway 192.168.1.1 and client ip 192.168.1.10 but no dice.
Under the circumstance that would be only possible with a UART I suppose.
Alternatively I could test the HBD medkits between Feb 05th and Feb 17th but could not find an archive tree for those builds in the repo.
Then (regression) bugs could be introduced into the HBD medkit, like it seems to be case now, and might go unnoticed until actually tested.
As said it did work earlier, the last with DHCP working I reported here been on Feb 05th, and then with the next test on Feb 17th the issue appeared. Also as stated tried the recent alpha2 and there is no issue with the medkit installation.
Then this is not clearly dhcp problem but rather system failed to start or something. Are you sure that you used correct medkit? Is router going trough standard leds blinking boot procedure? Is this state immediately after medkit flash?
HBD medkit is not tested and you should know that updater downgrades it do HBS unless you do switch-branch --verify hbd before you enable it. I am running HBD on multiple devices and I used medkit last week. Script generating it is the same as the one for HBS but HBD is unstable enough just because of upstream changes. So it makes almost no sense to automatically test something that has most of the time problems. Those are dragons, they throw fire and eat princesses. Using that and expecting stable experience is pretty much stupidity.
SFP does not work. Please next time think more about what you are using. PPPoE work and SFP is what is not. Time and time again you are proven wrong but still you think that it is good idea to go around forum and saying stuff like pppoe, second cpu, or switch does not work. Expecting that everything is going to work immediately and saying that because these things (that by the way work) are not working therefore you suspect us not working fast enough. I would say sorry that we are not good enough for you but your behaviour does not makes us happy and won’t convince us to work more. Most of your issues are just plain useless and undescribed and a lot of them are later resolved as something different. That is not plain bad and I have to give you that sometimes you stumble on something that is important and helps us. The problem is your approach. You feel entitled to criticize us during that time. Nobody likes that and just so you know most of your issues I am just ignoring at least for week or so because most of the times it turns out that is was just your mistake or something else. Nothing is immediate because there is just limited amount of work hours and I can’t be bothered to solve your problems outside of my work hours with your attitude. I am just asking you to think before you write. I would even say: thing ten times before you write, please.