Re: Nextcloud with httpd(8)
On 01.04., LÉVAI Dániel wrote:
> Hey Bruno!
>
Hi Dani
> That's the most curious thing, nothing shows up in the logs when the app
> says "Download failed/Could not download ".
> Tailing httpd's errorlog and Nextcloud's data/nextcloud.log yields
> nothing.
Have you checked the access log of httpd(8) too? If it is a http errror
4xx it will show up there, not in the error log.
> Raising loglevel for Nextcloud to debug only shows some image cache
> misses:
> {"reqId":"Wi7JHnvwCWAwkFbOr49Y","level":0,"time":"2019-04-01T13:06:41+00:00","remoteAddr":"IP","user":"username","app":"no
> app in
> context","method":"GET","url":"\/nextcloud\/ocs\/v2.php\/apps\/activity\/api\/v2\/activity\/filter?format=json=true=desc_type=files_id=213","message":"No
> cache entry found for \/appdata_ocvxn2n1q9gp\/theming\/images (storage:
> local::\/htdocs\/nextcloud\/data\/, internalPath:
> appdata_ocvxn2n1q9gp\/theming\/images)","userAgent":"Mozilla\/5.0 (Android)
> ownCloud-android\/3.5.1","version":"15.0.5.3"}
>
> I don't believe it's related, though.
>
Me neither. Do you see at least log entries for the connection from the
app to your Nextcloud?
>
> I can upload anything from the app, and I can do (even download)
> anything on Nextcloud's web UI. It's just the Android app that can't
> download anything. I thought that maybe this has still something to do
> with httpd(8) -- but it seems not :-\
>
How does your setup look like in detail? Any layer 7 proxy in front of
your Nextcloud?
>
> Dani
>
Cheers,
Bruno
Re: ARP issues when using ldpd and MPLS pseudowires
Hi Lee, Le 02/04/2019 13:53, Lee Nelson a écrit : I'm running a snapshot from March 31. It did fix a problem with split-horizon, but the arp/broadcast problem still exists. OK, then it's definitely something different. I'm not being flippant when I say you should log a bug. The guys who work on the code don't necessarily have the time to read misc@ or even tech@ religiously, but they do look at bug reports. My problem languished for a year until someone reminded me that bug reports were a thing. ;) Adrian
Re: ARP issues when using ldpd and MPLS pseudowires
Hi Henry,
Le 02/04/2019 13:39, Henry Bonath a écrit :
It looks like a patch may have been produced, but I do not know how to test
it. I'm not sure if I can pull down just a small part of the
OpenBSD source, or if the entire OS should be built. (Although I'd love to
learn how to do this)
Yup, there was a patch. It's been in the -current snapshots for a while
now (thanks dlg@), so you can just pull the latest ISO or whatever from
snapshots/ and install that to test. Probably not a bad idea, as I'm
not 100% sure my problem was the same as yours.
I tested the patch by installing a fresh system from the then-current
snapshot (without the patch), downloading src.tar.gz and sys.tar.gz from
6.4, untarring under /usr/src & /usr/src/sys, using CVS to update that
source to -current, applying the patch and then building the kernel
('bsd'). (There may be better ways, but that's how I did it.)
Then, copy the resulting 'bsd' file to / (keep a copy of the existing
one!) and reboot. Simple enough...
It was just a kernel patch so I didn't bother rebuilding the entire
userland, although that's advisable if you're planning on more extensive
testing.
Have a look at https://www.openbsd.org/faq/faq5.html for some hints and
feel free to ping me if you get stuck.
Adrian
Re: Trouble forwarding between mpw's in bridge (6.4)
Can you send me the hostname.* files and the output of ifconfig (showing all interfaces)? You're using -current now, right? dlg > On 2 Apr 2019, at 08:15, lnel...@nelnet.org wrote: > > >> Until recently >> (https://github.com/openbsd/src/commit/dc68b945bbc883db108ac48a07bb89 >> 778b75582a) >> bridge did split horizon detection by not allowing you to send >> between >> two mpw interfaces. In the case of a single VPLS this is the correct >> thing, but more generally it isn't quite right. Particularly when you >> want to bridge two seperate VPLS's. It's been removed now, and to >> achieve proper VPLS functionality with the change applied I found I >> had >> to add all mpw interfaces in the same VPLS to the same protected >> domain. >> >> If you update to current your config will probably work, but be >> mindful >> that for a full mesh VPLS if you don't put them in a protected domain >> you'll probably get a full mesh of broadcasts. > > Thanks. Your advice on upgrading the OS along with a hack of my own > got me to a working state, but it isn't a sustainable or stable state. > I installed the March 31 snapshot and the split-horizon problem was > resolved. However, there is still a problem with arp (and probably all > broadcast traffic, but I never get past arp). If I create a static arp > for rtr01 on rtr02 and rtr02 on rtr01, then everything else works. I > can send traffic back and forth between routers over the pseudowires. > This is a hack that works for now, but it's not really a solution. > > First of all the protected domain seems to do the opposite of what I > need, but it may only appear to be the case because of the strageness > with broadcast. When trying to ping (or send any traffic) between > rtr01 and rtr02 and the two mpw2's are in the same protected domain, > the arp requests die in the bridge. The arp never shows up at all on > the other mpw. If I remove the mpw's from the protected domain, then > the arp traffic gets through to the other mpw, but it doesn't get sent > out properly by MPLS. It's sent out as MPLS broadcast traffic > originating on the physical ethernet interface but with the right label > for the pseudowire. Even though the arp request itself is broadcast > traffic, I would expect it to be encapsulated in a unicast MPLS packet > which is sent from the MAC of the bridge or the originating router and > and sent as unicast to the destination router with the pseudowire's > label. As it is now, even if the destination router could figure out > what to do with these MPLS broadcast packets, it would respond to the > physical interface and not the bridge. > > Without the protected domain, this is what I see on both mpw > interfaces: > 11 4.015737 02:3b:c0:60:4c:95 ? ff:ff:ff:ff:ff:ff ARP 42 Who has > 192.168.99.2? Tell 192.168.99.3 >12 4.015751 02:3b:c0:60:4c:95 ? ff:ff:ff:ff:ff:ff ARP 42 Who has > 192.168.99.2? Tell 192.168.99.3 >13 5.015772 02:3b:c0:60:4c:95 ? ff:ff:ff:ff:ff:ff ARP 42 Who has > > With the protected domain, I only see these packets on the incoming > mpw. > > The destination router sees this: > 189 15.137231 6c:b3:11:4b:07:d4 ff:ff:ff:ff:ff:ff > MPLS 60 MPLS Label Switched Packet > 202 16.161025 6c:b3:11:4b:07:d4 ff:ff:ff:ff:ff:ff > MPLS 60 MPLS Label Switched Packet > 213 17.157232 6c:b3:11:4b:07:d4 ff:ff:ff:ff:ff:ff > MPLS 60 MPLS Label Switched Packet > > 02:3b:c0:60:4c:95 is the originating router. > 6c:b3:11:4b:07:d4 is the physical interface facing the destination > router > > By examining the MPLS packets I could see they were being sent to the > right label. I haven't figured out how to decode the payload, but it's > 42 bytes which is the exact same length as the inbound arp packets. > > Maybe I'm making wrong assumptions here. I would expect that either > the bridge does proxy arp or that the bridge would re-encapsulate > broadcast packets back into unicast MPLS/VPLS packets on the pseudwire > which then gets unencapsulated by the destination router and treated as > broadcast there. Meanwhile, of course, it would also broadcast that > same arp request out any other interface in the same bridge. >
Re: ARP issues when using ldpd and MPLS pseudowires
Hi guys, Le 02/04/2019 13:18, Lee Nelson a écrit : This sounds very similar to the problem I mentioned over the last couple of days in an email with the subject "Trouble forwarding between mpw's in bridge (6.4)". Sorry, I posted a follow-up to my message in tech@ but not misc@. I ended up finally logging an actual bug, which dlg@ picked up, and he put a fix in -current that fixed my problem completely. Try a current snapshot and see if that helps? Adrian
Re: ARP issues when using ldpd and MPLS pseudowires
Thanks for the follow-up Adrian, I will build one out and give it a test here tomorrow. On Mon, Apr 1, 2019 at 10:42 PM Adrian Close wrote: > Hi guys, > > Le 02/04/2019 13:18, Lee Nelson a écrit : > > This sounds very similar to the problem I mentioned over the last couple > of > > days in an email with the subject "Trouble forwarding between mpw's in > > bridge (6.4)". > Sorry, I posted a follow-up to my message in tech@ but not misc@. I > ended up finally logging an actual bug, which dlg@ picked up, and he put > a fix in -current that fixed my problem completely. > > Try a current snapshot and see if that helps? > > Adrian >
Re: ARP issues when using ldpd and MPLS pseudowires
I'm running a snapshot from March 31. It did fix a problem with split-horizon, but the arp/broadcast problem still exists. On Mon, Apr 1, 2019, 19:42 Adrian Close wrote: > Hi guys, > > Le 02/04/2019 13:18, Lee Nelson a écrit : > > This sounds very similar to the problem I mentioned over the last couple > of > > days in an email with the subject "Trouble forwarding between mpw's in > > bridge (6.4)". > Sorry, I posted a follow-up to my message in tech@ but not misc@. I > ended up finally logging an actual bug, which dlg@ picked up, and he put > a fix in -current that fixed my problem completely. > > Try a current snapshot and see if that helps? > > Adrian >
Re: ARP issues when using ldpd and MPLS pseudowires
Lee, I just read your post about 5 minutes before you sent this. I agree that I think this is all related. I'm not running Pseudowires in my environment, only L3VPN but we're all talking MPLS here. I came across this thread from the dev mailing list posted by (who I can assume is) the Adrian Close that started this thread: http://openbsd-archive.7691.n7.nabble.com/ARP-issues-when-using-ldpd-8-and-mpw-4-td360853.html It looks like a patch may have been produced, but I do not know how to test it. I'm not sure if I can pull down just a small part of the OpenBSD source, or if the entire OS should be built. (Although I'd love to learn how to do this) If I'm reading this right, the issue is in if_ethersubr.c and the issue is with running LDP, when ARP'ing for a neighbor, ARP "who has" requests go out for the Address of the LDP ID of the neighbor router, not the directly broadcast-adjacent Address. In my case, I run Loopbacks advertised into OSPF and use those for LDP and BGP. ARP requests go out for those Loopback IP addresses which are not broadcast-adjacent, causing my ARP entries to go expired/incomplete. (ARP should know that these addresses are not in my subnet mask and therefore should not be sending ARPs for those addresses!) If someone could help me get this patch built, I'd gladly reach back to the Developer to see if we could get this rolled into a syspatch or maybe into 6.5 which is right around the corner I'm assuming. I have not tested MPLS on 6.5 as of yet. On Mon, Apr 1, 2019 at 10:18 PM Lee Nelson wrote: > This sounds very similar to the problem I mentioned over the last couple > of days in an email with the subject "Trouble forwarding between mpw's in > bridge (6.4)". > > Our environments are very different, but I think the underlying problem > may be the same. In short, arp inside of a bridge works as it should except > between mpw's (pseudowires). An arp broadcast entering the bridge on one > mpw exits the bridge properly on physical interfaces, but does not get > properly encapsulated onto the other mpw. The problem probably affects all > broadcast traffic, but so far arp is the only broadcast traffic I have > dealt with. Like you, I have to statically configure entries in the arp > tables. This hack does not scale. > > On Mon, Apr 1, 2019, 18:36 Henry Bonath wrote: > >> Tom, Adrian, et al - >> >> I have posted before about this issue a few weeks ago - apparently this >> affects more than just >> Virtualbox or VMWare, I am experiencing this *EXACT* thing on Hyper-V as >> well. >> I have not tried this on metal. >> >> My network looks like this: >> >> (Customer VMs)<--->(Hyper-V OpenBSD 6.4 PE)<--->(CISCO ASR P)<--->(CISCO >> ME3750 PE)<--->(CE) >> They Layer-2 between the Hyper-V and Cisco ASR is a Cisco Nexus 5672. >> I am using L3VPN instead of Pseudowire. >> >> Some of the ARP entries will time out and when they do, LDP will crash. >> (ldp engine terminated; signal 10) >> 100.92.64.37 (incomplete) hvn0 expired >> < ARP timed out >> 100.92.64.68 00:b7:71:93:32:95hvn0 6m8s < >> ARP about to time out >> >> ARP Timing out makes no sense as these devices are all running OSPF with >> each other, >> granted OSPF is running Multicast to 224.0.0.5 I would think that would be >> enough to keep ARP up. >> >> In my environment I use Salt to manage my systems, and my PE formula has >> static ARP entries >> that get added, but that's not really a fix but a workaround. >> >> 100.92.64.37 (incomplete) hvn0 expired >> <--- ARP still missing for this guy >> 100.92.64.68 00:b7:71:93:32:95hvn0 expired >> <--- ARP timed out while writing this >> >> # ping 100.92.64.68 >> PING 100.92.64.68 (100.92.64.68): 56 data bytes >> ping: sendmsg: Host is down >> ping: wrote 100.92.64.68 64 chars, ret=-1 >> ping: sendmsg: Host is down >> >> Other ARP Entries stay up, the ones that do not run LDP, and oddly enough- >> other OpenBSD systems. >> It seems like this only happens to OpenBSD LDP against Cisco IOS/IOS-XE >> (in >> my environment, anyway) >> >> -Henry >> >> >> On Wed, Mar 13, 2019 at 7:28 PM Tom Smyth >> wrote: >> >> > Adrian, >> > sorry I only saw this now ... when trying to go through old unread >> mails >> > >> > I would be very wary of vmware virtual networking and Layer 2 >> Forwarding >> > I loved vmware before I discovered the ridiculous short comings in >> > their virtual networks >> > >> > Vmware Virtual Switches vmxnet >> > they are not switches or bridges... :( they (vmware) over optimised >> > and the virtual switches forward too and from vms by default based on >> > macs learned >> > via each attached machines vmx config file. >> > the workaround is promiscuous mode for the virtual switch... (turns >> > your virtual switch into >> > a crappy hub) >> > but this copies packets (frames) that are destined >> > for 1 machine virtual machine attached to the
Re: ARP issues when using ldpd and MPLS pseudowires
This sounds very similar to the problem I mentioned over the last couple of days in an email with the subject "Trouble forwarding between mpw's in bridge (6.4)". Our environments are very different, but I think the underlying problem may be the same. In short, arp inside of a bridge works as it should except between mpw's (pseudowires). An arp broadcast entering the bridge on one mpw exits the bridge properly on physical interfaces, but does not get properly encapsulated onto the other mpw. The problem probably affects all broadcast traffic, but so far arp is the only broadcast traffic I have dealt with. Like you, I have to statically configure entries in the arp tables. This hack does not scale. On Mon, Apr 1, 2019, 18:36 Henry Bonath wrote: > Tom, Adrian, et al - > > I have posted before about this issue a few weeks ago - apparently this > affects more than just > Virtualbox or VMWare, I am experiencing this *EXACT* thing on Hyper-V as > well. > I have not tried this on metal. > > My network looks like this: > > (Customer VMs)<--->(Hyper-V OpenBSD 6.4 PE)<--->(CISCO ASR P)<--->(CISCO > ME3750 PE)<--->(CE) > They Layer-2 between the Hyper-V and Cisco ASR is a Cisco Nexus 5672. > I am using L3VPN instead of Pseudowire. > > Some of the ARP entries will time out and when they do, LDP will crash. > (ldp engine terminated; signal 10) > 100.92.64.37 (incomplete) hvn0 expired > < ARP timed out > 100.92.64.68 00:b7:71:93:32:95hvn0 6m8s < > ARP about to time out > > ARP Timing out makes no sense as these devices are all running OSPF with > each other, > granted OSPF is running Multicast to 224.0.0.5 I would think that would be > enough to keep ARP up. > > In my environment I use Salt to manage my systems, and my PE formula has > static ARP entries > that get added, but that's not really a fix but a workaround. > > 100.92.64.37 (incomplete) hvn0 expired > <--- ARP still missing for this guy > 100.92.64.68 00:b7:71:93:32:95hvn0 expired > <--- ARP timed out while writing this > > # ping 100.92.64.68 > PING 100.92.64.68 (100.92.64.68): 56 data bytes > ping: sendmsg: Host is down > ping: wrote 100.92.64.68 64 chars, ret=-1 > ping: sendmsg: Host is down > > Other ARP Entries stay up, the ones that do not run LDP, and oddly enough- > other OpenBSD systems. > It seems like this only happens to OpenBSD LDP against Cisco IOS/IOS-XE (in > my environment, anyway) > > -Henry > > > On Wed, Mar 13, 2019 at 7:28 PM Tom Smyth > wrote: > > > Adrian, > > sorry I only saw this now ... when trying to go through old unread > mails > > > > I would be very wary of vmware virtual networking and Layer 2 Forwarding > > I loved vmware before I discovered the ridiculous short comings in > > their virtual networks > > > > Vmware Virtual Switches vmxnet > > they are not switches or bridges... :( they (vmware) over optimised > > and the virtual switches forward too and from vms by default based on > > macs learned > > via each attached machines vmx config file. > > the workaround is promiscuous mode for the virtual switch... (turns > > your virtual switch into > > a crappy hub) > > but this copies packets (frames) that are destined > > for 1 machine virtual machine attached to the virtual switch, so if > > you have high traffic volumes > > and alot of machines attached to the virtual lan ... your perf is > > going to suck ... > > also you need to allow forged transmits on the virtual switch (macs > > that dont match the vmx machine > > mac configuration (which all bridged packets from behind your openbsd > > guest will appear as ... > > > > if you are desperate to use vmware .. .check out the labs... they had > > an "improved" > > virtual switch with mac learning capabilities ... (only down side is > > that particular virtual switch > > has no mac ageing on the switch your virtual switch FIB wont flush > > without rebooting the host > > > > apparently vmware have a switch that has proper mac learning from > > virtual machines that > > are bridging , but this requires the super duper awesome license (the > > enterprise + or something like that, > > > > If you still need to use vmware on a lesser license perhaps a > > multiport card + sriov and avoid their poor virtual switches > > > > basically you will have a lot of hassle with that, > > > > I hope this helps ... 352 days later :/ > > > > Tom Smyth > > PS > > Einstein once said " you should make things as simple as possible but > > no simpler" it would appear vmware > > did not heed this advice... and you dont have to be a genius to work > > that out ... :) (because I did :) ) > > > > On Fri, 16 Mar 2018 at 04:55, Adrian Close > > wrote: > > > > > > Hi, > > > > > > I'm looking at doing some MPLS/VPLS stuff with OpenBSD, in particular > > > using 'mpw' pseudowires. I've created a test network comprising two > > > "PE" and two "P" hosts, to
Relayd Crashing in transparent mode
Wondering if someone can help point me in the right direction.
relayd keeps crashing on me, I suspect someone is attacking using corrupted
packets in someway.
Other attacks are much higher than normal (application layer)
States look look inline (less than 5k) processor usage about 20 percent
Running on KVM, Fully patched -Stable (6.4)
Anyway right before the relay stop working, I am getting errors such as:
session failed: Operation timed out
bindany failed, invalid socket: Invalid argument
Socket is not connected: Socket is not connected
relay exiting, pid [X]
Can anyone point me in the right direction to get more logging/how to
investigate the errors I am getting?
rcctl restart relayd always fixes the issue
interment problem, but when an issue it will crash every couple minutes
Config is:
interval 30
log state changes
log connection
prefork 10
vip01 = "159.100.208.71"
table { 10.5.6.121 10.5.6.171 }
relay webRedirect0180 {
listen on $vip01 port 80
transparent forward to port 80 \
mode loadbalance check tcp
}
relay webRedirect01443 {
listen on $vip01 port 443
transparent forward to port 443 \
mode loadbalance check tcp
}
...repeats about 20 times w/ different VIPs
Re: ARP issues when using ldpd and MPLS pseudowires
Tom, Adrian, et al - I have posted before about this issue a few weeks ago - apparently this affects more than just Virtualbox or VMWare, I am experiencing this *EXACT* thing on Hyper-V as well. I have not tried this on metal. My network looks like this: (Customer VMs)<--->(Hyper-V OpenBSD 6.4 PE)<--->(CISCO ASR P)<--->(CISCO ME3750 PE)<--->(CE) They Layer-2 between the Hyper-V and Cisco ASR is a Cisco Nexus 5672. I am using L3VPN instead of Pseudowire. Some of the ARP entries will time out and when they do, LDP will crash. (ldp engine terminated; signal 10) 100.92.64.37 (incomplete) hvn0 expired < ARP timed out 100.92.64.68 00:b7:71:93:32:95hvn0 6m8s < ARP about to time out ARP Timing out makes no sense as these devices are all running OSPF with each other, granted OSPF is running Multicast to 224.0.0.5 I would think that would be enough to keep ARP up. In my environment I use Salt to manage my systems, and my PE formula has static ARP entries that get added, but that's not really a fix but a workaround. 100.92.64.37 (incomplete) hvn0 expired <--- ARP still missing for this guy 100.92.64.68 00:b7:71:93:32:95hvn0 expired <--- ARP timed out while writing this # ping 100.92.64.68 PING 100.92.64.68 (100.92.64.68): 56 data bytes ping: sendmsg: Host is down ping: wrote 100.92.64.68 64 chars, ret=-1 ping: sendmsg: Host is down Other ARP Entries stay up, the ones that do not run LDP, and oddly enough- other OpenBSD systems. It seems like this only happens to OpenBSD LDP against Cisco IOS/IOS-XE (in my environment, anyway) -Henry On Wed, Mar 13, 2019 at 7:28 PM Tom Smyth wrote: > Adrian, > sorry I only saw this now ... when trying to go through old unread mails > > I would be very wary of vmware virtual networking and Layer 2 Forwarding > I loved vmware before I discovered the ridiculous short comings in > their virtual networks > > Vmware Virtual Switches vmxnet > they are not switches or bridges... :( they (vmware) over optimised > and the virtual switches forward too and from vms by default based on > macs learned > via each attached machines vmx config file. > the workaround is promiscuous mode for the virtual switch... (turns > your virtual switch into > a crappy hub) > but this copies packets (frames) that are destined > for 1 machine virtual machine attached to the virtual switch, so if > you have high traffic volumes > and alot of machines attached to the virtual lan ... your perf is > going to suck ... > also you need to allow forged transmits on the virtual switch (macs > that dont match the vmx machine > mac configuration (which all bridged packets from behind your openbsd > guest will appear as ... > > if you are desperate to use vmware .. .check out the labs... they had > an "improved" > virtual switch with mac learning capabilities ... (only down side is > that particular virtual switch > has no mac ageing on the switch your virtual switch FIB wont flush > without rebooting the host > > apparently vmware have a switch that has proper mac learning from > virtual machines that > are bridging , but this requires the super duper awesome license (the > enterprise + or something like that, > > If you still need to use vmware on a lesser license perhaps a > multiport card + sriov and avoid their poor virtual switches > > basically you will have a lot of hassle with that, > > I hope this helps ... 352 days later :/ > > Tom Smyth > PS > Einstein once said " you should make things as simple as possible but > no simpler" it would appear vmware > did not heed this advice... and you dont have to be a genius to work > that out ... :) (because I did :) ) > > On Fri, 16 Mar 2018 at 04:55, Adrian Close > wrote: > > > > Hi, > > > > I'm looking at doing some MPLS/VPLS stuff with OpenBSD, in particular > > using 'mpw' pseudowires. I've created a test network comprising two > > "PE" and two "P" hosts, to transport Ethernet traffic between service > > ports on the PE hosts across the MPLS network, based on an example I > > found online. I'm using a 6.3 snapshot from March 11th. > > > >[firewall] = [em0][mpw0][PE1][em1] - [em0][P1][em1] - [em1][P2][em0] > > - [em1][PE2][mpw0][em0] = [host] > > > > PE1 em0 and mpw0 are in a bridge, PE1 em1 is MPLS, P1 em0/1 are MPLS etc. > > > > This is all working great, except for short outages which turn out to > > coincide with the ARP cache expiry time for the P router's IP address on > > the PE host. > > > > When the ARP entry times out (or is manually deleted), the PE host > > doesn't ARP for the P router IP, but instead sends ARP who-has queries > > for other, definitely non-local things, such as the IP address for the > > other PE host's router-id. After a minute or so it finally ARPs for the > > P router IP and things work again. > > > > This only happens when "ldpd" is running (and I think only when the > >
Re: Trouble forwarding between mpw's in bridge (6.4)
> Until recently > (https://github.com/openbsd/src/commit/dc68b945bbc883db108ac48a07bb89 > 778b75582a) > bridge did split horizon detection by not allowing you to send > between > two mpw interfaces. In the case of a single VPLS this is the correct > thing, but more generally it isn't quite right. Particularly when you > want to bridge two seperate VPLS's. It's been removed now, and to > achieve proper VPLS functionality with the change applied I found I > had > to add all mpw interfaces in the same VPLS to the same protected > domain. > > If you update to current your config will probably work, but be > mindful > that for a full mesh VPLS if you don't put them in a protected domain > you'll probably get a full mesh of broadcasts. Thanks. Your advice on upgrading the OS along with a hack of my own got me to a working state, but it isn't a sustainable or stable state. I installed the March 31 snapshot and the split-horizon problem was resolved. However, there is still a problem with arp (and probably all broadcast traffic, but I never get past arp). If I create a static arp for rtr01 on rtr02 and rtr02 on rtr01, then everything else works. I can send traffic back and forth between routers over the pseudowires. This is a hack that works for now, but it's not really a solution. First of all the protected domain seems to do the opposite of what I need, but it may only appear to be the case because of the strageness with broadcast. When trying to ping (or send any traffic) between rtr01 and rtr02 and the two mpw2's are in the same protected domain, the arp requests die in the bridge. The arp never shows up at all on the other mpw. If I remove the mpw's from the protected domain, then the arp traffic gets through to the other mpw, but it doesn't get sent out properly by MPLS. It's sent out as MPLS broadcast traffic originating on the physical ethernet interface but with the right label for the pseudowire. Even though the arp request itself is broadcast traffic, I would expect it to be encapsulated in a unicast MPLS packet which is sent from the MAC of the bridge or the originating router and and sent as unicast to the destination router with the pseudowire's label. As it is now, even if the destination router could figure out what to do with these MPLS broadcast packets, it would respond to the physical interface and not the bridge. Without the protected domain, this is what I see on both mpw interfaces: 11 4.015737 02:3b:c0:60:4c:95 ? ff:ff:ff:ff:ff:ff ARP 42 Who has 192.168.99.2? Tell 192.168.99.3 12 4.015751 02:3b:c0:60:4c:95 ? ff:ff:ff:ff:ff:ff ARP 42 Who has 192.168.99.2? Tell 192.168.99.3 13 5.015772 02:3b:c0:60:4c:95 ? ff:ff:ff:ff:ff:ff ARP 42 Who has With the protected domain, I only see these packets on the incoming mpw. The destination router sees this: 189 15.137231 6c:b3:11:4b:07:d4 ff:ff:ff:ff:ff:ff MPLS60 MPLS Label Switched Packet 202 16.161025 6c:b3:11:4b:07:d4 ff:ff:ff:ff:ff:ff MPLS60 MPLS Label Switched Packet 213 17.157232 6c:b3:11:4b:07:d4 ff:ff:ff:ff:ff:ff MPLS60 MPLS Label Switched Packet 02:3b:c0:60:4c:95 is the originating router. 6c:b3:11:4b:07:d4 is the physical interface facing the destination router By examining the MPLS packets I could see they were being sent to the right label. I haven't figured out how to decode the payload, but it's 42 bytes which is the exact same length as the inbound arp packets. Maybe I'm making wrong assumptions here. I would expect that either the bridge does proxy arp or that the bridge would re-encapsulate broadcast packets back into unicast MPLS/VPLS packets on the pseudwire which then gets unencapsulated by the destination router and treated as broadcast there. Meanwhile, of course, it would also broadcast that same arp request out any other interface in the same bridge.
Re: Touchpad - how to enable two-finger scrolling
On 4/1/19 2:18 AM, Brogan wrote: > Understood. That would make sense as when I run a wsconsctl I see > mouse.type=ps2. Would that be indicative of the hardware being unsupported? > [...] Yes, that's correct. (I assume it's an ALPS model with a protocol version that isn't implemented in pms.) > [...] I've provided my dmesg below: > > > OpenBSD 6.4 (GENERIC.MP) #364: Thu Oct 11 13:30:23 MDT 2018 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 8472076288 (8079MB) > avail mem = 8206049280 (7825MB) > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xebf40 (92 entries) > bios0: vendor Dell Inc. version "A15" date 11/30/2018 > bios0: Dell Inc. Latitude 6430U > acpi0 at bios0: rev 2 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT SSDT SSDT DMAR ASF! SLIC BGRT > acpi0: wakeup devices P0P1(S4) USB1(S3) USB2(S3) USB3(S3) USB5(S3) USB6(S3) > USB7(S3) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP05(S4) PXSX(S4) > RP06(S4) PXSX(S4) [...] > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Core(TM) i7-3687U CPU @ 2.10GHz, 1993.85 MHz, 06-3a-09 > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu0: 256KB 64b/line 8-way L2 cache > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges > cpu0: apic clock running at 99MHz > cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE > cpu1 at mainbus0: apid 2 (application processor) > cpu1: Intel(R) Core(TM) i7-3687U CPU @ 2.10GHz, 1993.53 MHz, 06-3a-09 > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu1: 256KB 64b/line 8-way L2 cache > cpu1: smt 0, core 1, package 0 > cpu2 at mainbus0: apid 1 (application processor) > cpu2: Intel(R) Core(TM) i7-3687U CPU @ 2.10GHz, 1993.53 MHz, 06-3a-09 > cpu2: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu2: 256KB 64b/line 8-way L2 cache > cpu2: smt 1, core 0, package 0 > cpu3 at mainbus0: apid 3 (application processor) > cpu3: Intel(R) Core(TM) i7-3687U CPU @ 2.10GHz, 1993.53 MHz, 06-3a-09 > cpu3: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu3: 256KB 64b/line 8-way L2 cache > cpu3: smt 1, core 1, package 0 > ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins > acpimcfg0 at acpi0 > acpimcfg0: addr 0xf800, bus 0-63 > acpihpet0 at acpi0: 14318179 Hz > acpiprt0 at acpi0: bus 0 (PCI0) > acpiprt1 at acpi0: bus -1 (P0P1) > acpiprt2 at acpi0: bus 1 (RP01) > acpiprt3 at acpi0: bus 2 (RP02) > acpiprt4 at acpi0: bus -1 (RP05) > acpiprt5 at acpi0: bus 3 (RP06) > acpiprt6 at acpi0: bus -1 (RP07) > acpiprt7 at acpi0: bus -1 (RP08) > acpiprt8 at acpi0: bus -1 (PEG0) > acpiprt9 at acpi0: bus -1 (PEG1) > acpiprt10 at acpi0: bus -1 (PEG2) > acpiprt11 at acpi0: bus -1 (PEG3) > acpiprt12 at acpi0: bus -1 (RP03) > acpiprt13 at acpi0: bus -1 (RP04) > acpiec0 at acpi0 > acpicpu0 at acpi0: C3(200@87 mwait.1@0x30), C2(500@59 mwait.1@0x10), > C1(1000@1 mwait.1), PSS > acpicpu1 at acpi0: C3(200@87 mwait.1@0x30), C2(500@59 mwait.1@0x10), > C1(1000@1 mwait.1), PSS > acpicpu2 at acpi0: C3(200@87 mwait.1@0x30), C2(500@59 mwait.1@0x10), > C1(1000@1 mwait.1), PSS > acpicpu3 at acpi0: C3(200@87 mwait.1@0x30), C2(500@59 mwait.1@0x10), > C1(1000@1 mwait.1), PSS > acpitz0 at acpi0: critical temperature is 107 degC > acpicmos0 at acpi0 > "*pnp0c14" at acpi0 not configured > acpibtn0 at acpi0: LID0 > acpibtn1 at acpi0: PBTN > acpibtn2 at acpi0: SBTN > acpiac0 at acpi0: AC unit offline > acpibat0 at acpi0: BAT0 model "DELL TRM4D5B" serial 189 type LiP oem "Sanyo" > "DELLABCE" at acpi0 not configured
Re: Nextcloud with httpd(8)
Hey Bruno!
That's the most curious thing, nothing shows up in the logs when the app
says "Download failed/Could not download ".
Tailing httpd's errorlog and Nextcloud's data/nextcloud.log yields
nothing.
Raising loglevel for Nextcloud to debug only shows some image cache
misses:
{"reqId":"Wi7JHnvwCWAwkFbOr49Y","level":0,"time":"2019-04-01T13:06:41+00:00","remoteAddr":"IP","user":"username","app":"no
app in
context","method":"GET","url":"\/nextcloud\/ocs\/v2.php\/apps\/activity\/api\/v2\/activity\/filter?format=json=true=desc_type=files_id=213","message":"No
cache entry found for \/appdata_ocvxn2n1q9gp\/theming\/images (storage:
local::\/htdocs\/nextcloud\/data\/, internalPath:
appdata_ocvxn2n1q9gp\/theming\/images)","userAgent":"Mozilla\/5.0 (Android)
ownCloud-android\/3.5.1","version":"15.0.5.3"}
I don't believe it's related, though.
I can upload anything from the app, and I can do (even download)
anything on Nextcloud's web UI. It's just the Android app that can't
download anything. I thought that maybe this has still something to do
with httpd(8) -- but it seems not :-\
Dani
Bruno Flückiger @ 2019-04-01T11:11:18 +0200:
> On 01.04., LÉVAI Dániel wrote:
> > Hi all!
> >
> > After reading this
> > https://marc.info/?l=openbsd-misc=149420565311794=2
> > .. and this
> > https://github.com/nextcloud/android/issues/113#issuecomment-478398248
> >
> > I'm still wondering why would my file download with the Android app fail
> > with nextcloud 15.0.5 on OpenBSD 6.4-stable.
> >
> > By any chance, does anyone here use nextcloud from ports on OpenBSD with
> > httpd(8) and the infamous Nextcloud Android app?
> >
> >
> > Dani
> >
> > --
> > LÉVAI Dániel
> > PGP key ID = 0x83B63A8F
> > Key fingerprint = DBEC C66B A47A DFA2 792D 650C C69B BE4C 83B6 3A8F
> >
>
> Hi Dani
>
> I do run Nextcloud on httpd(8) and use the Android app. I don't have
> this problem anymore since they fixed it in the Android app. What do you
> see in the logs if your download fails?
>
> Cheers,
> Bruno
--
LÉVAI Dániel
PGP key ID = 0x83B63A8F
Key fingerprint = DBEC C66B A47A DFA2 792D 650C C69B BE4C 83B6 3A8F
Re: Nextcloud with httpd(8)
On 01.04., LÉVAI Dániel wrote: > Hi all! > > After reading this > https://marc.info/?l=openbsd-misc=149420565311794=2 > .. and this > https://github.com/nextcloud/android/issues/113#issuecomment-478398248 > > I'm still wondering why would my file download with the Android app fail > with nextcloud 15.0.5 on OpenBSD 6.4-stable. > > By any chance, does anyone here use nextcloud from ports on OpenBSD with > httpd(8) and the infamous Nextcloud Android app? > > > Dani > > -- > LÉVAI Dániel > PGP key ID = 0x83B63A8F > Key fingerprint = DBEC C66B A47A DFA2 792D 650C C69B BE4C 83B6 3A8F > Hi Dani I do run Nextcloud on httpd(8) and use the Android app. I don't have this problem anymore since they fixed it in the Android app. What do you see in the logs if your download fails? Cheers, Bruno
Re: Trouble forwarding between mpw's in bridge (6.4)
On 1/04/2019 3:31 pm, lnel...@nelnet.org wrote: > I am having trouble passing traffic between pseudowires in a bridge in > OpenBSD 6.4. This is the network: > Until recently (https://github.com/openbsd/src/commit/dc68b945bbc883db108ac48a07bb89778b75582a) bridge did split horizon detection by not allowing you to send between two mpw interfaces. In the case of a single VPLS this is the correct thing, but more generally it isn't quite right. Particularly when you want to bridge two seperate VPLS's. It's been removed now, and to achieve proper VPLS functionality with the change applied I found I had to add all mpw interfaces in the same VPLS to the same protected domain. If you update to current your config will probably work, but be mindful that for a full mesh VPLS if you don't put them in a protected domain you'll probably get a full mesh of broadcasts.
Nextcloud with httpd(8)
Hi all! After reading this https://marc.info/?l=openbsd-misc=149420565311794=2 ... and this https://github.com/nextcloud/android/issues/113#issuecomment-478398248 I'm still wondering why would my file download with the Android app fail with nextcloud 15.0.5 on OpenBSD 6.4-stable. By any chance, does anyone here use nextcloud from ports on OpenBSD with httpd(8) and the infamous Nextcloud Android app? Dani -- LÉVAI Dániel PGP key ID = 0x83B63A8F Key fingerprint = DBEC C66B A47A DFA2 792D 650C C69B BE4C 83B6 3A8F
