<azonenberg>
they had a tech out at the pole on the street poking around
<azonenberg>
you'll never guess what he found, lol
<rqou>
while my comcast connection was having problems the past few hours
<rqou>
:P
<rqou>
when your CM is showing around 600 million uncorrectable octets on a downstream channel, something _might_ be wrong :P :P
<rqou>
enough rebooting seems to have fixed the issue for now
<azonenberg>
lol
<azonenberg>
see i never had downstream issues
<azonenberg>
i had upstream issues
<rqou>
over half the time was me trying to figure out if the problem was comcast or netfilter
<azonenberg>
as well as random total link loss problems
<azonenberg>
So, the guy was up on the pole and found an old splitter
<azonenberg>
he figured he'd replace it
<azonenberg>
While he was at it, he tried ripping out the cable from the top of the pole and the splitter to the junction box in the ground that went to the house (long-haul wiring is above ground but the run to the house is buried)
<azonenberg>
And apparently the termination on that cable wasn't crimped
<azonenberg>
not like, bad crimp that had come loose
<azonenberg>
There was no evidence of any crimp whatsoever
<rqou>
wtf
<rqou>
lol cable installers
<azonenberg>
So apparently my internet connection over the last ~2 years has been held together by friction and dumb luck
<azonenberg>
and any time thermal expansion and wind added up wrong, i went down
<rqou>
hey, a small break just looks like a capacitor!
<azonenberg>
Lol
<rqou>
this is called a "distributed element filter" :P
<azonenberg>
That probably explains why i was having problems with upstream attenuation more than downstream
<rqou>
lool
<azonenberg>
there's a lot more noise margin rx'ing a strong signal from the head end
<azonenberg>
than a weak signal from the modem
<azonenberg>
My modem was putting out like 20 dB more than it was supposed to trying to jump the gap
<rqou>
there are loops of cable hanging along the wall because "on top of the NAS box" ran out of space :P
<azonenberg>
lolol
<rqou>
right now an RG6 coax runs out from below the gap of the door on the right hand side
<rqou>
it then runs up the door frame and around
<rqou>
and plugs into the CM that is sitting on top of the nas box
<rqou>
there is then a 1ft ethernet cable connecting that into the nas
<rqou>
the nas then does routing
<rqou>
then there's a 3ft direct attach cable to the switch below it
<rqou>
because 3ft is a lot more cost effective than 1ft for direct attach
<rqou>
:P
<rqou>
there are then two cat6?? cables leaving the switch in a link aggregation group
<rqou>
they're blue and white because we didn't buy them at the same time :P
<rqou>
then then run across the door frame again to the other shelf
<rqou>
there there is a meraki layer 2 switch
<rqou>
this is actually required and can't be replaced by the rackmount switch because:
<rqou>
a) one of the cables going into it isn't long enough to cross the doorframe
<rqou>
b) it's a PoE injector for the AP
<azonenberg>
lool
<rqou>
anyways, then a cable leaves from the meraki switch
<rqou>
and crosses the doorframe _yet again_
<rqou>
to plug into the AP sitting on top of the nas box
<rqou>
this is also required because due to physical geometry the downstairs attenuation is better in this spot :P
<rqou>
an extension cord crossing the door frame then completes the picture :P :P
<azonenberg>
lol
digshadow has quit [Quit: Leaving.]
<rqou>
on a different note, the lb4m has a totally different idea of "how to vlan" compared to everybody else it seems
<rqou>
which can lead to exciting multi-hour-long debugging sessions
<rqou>
on the meraki equipment, there is a configuration setting of "native VLAN"
<rqou>
which basically means that untagged traffic entering will be assigned that VLAN, and apparently also that traffic leaving that matches that VLAN will leave untagged
<rqou>
if a tagged vlan enters matching the "native VLAN" the switch accepts it and the AP gets confused and drops it
<rqou>
er, correction
<rqou>
the AP doesn't do "native VLANs" exactly the same way so if you assign an SSID to a VLAN
<rqou>
and the switch sends it an untagged frame, the AP drops it
<rqou>
meanwhile the lb4m has a PVID setting for assigning a vlan to received packets
<rqou>
but sending is configured completely independently
<rqou>
you can make any vlan leave any port tagged or untagged
<rqou>
which is great except that that part is in a totally different menu :P
<azonenberg_work>
rqou: meanwhile when i build a switch
<azonenberg_work>
i plan to not have a native vlan (way too error prone, security risks, etc)
<azonenberg_work>
if a port is not a trunk, any .1q traffic coming in gets dropped
<azonenberg_work>
If a port is a trunk, any untagged traffic is dropped
<rqou>
that's how i expect it to reasonably work
<rqou>
the lb4m can do that after you menu hard enough
<azonenberg_work>
there is no good reason to allow untagged traffic on a trunk port
<azonenberg_work>
or tagged traffic on an access port
<rqou>
meraki defaults all ports to "trunk, native vlan 1"
<rqou>
so if you want to send vlan tags it accepts them
<azonenberg_work>
that sounds stupid easy to vlan hop out of
<azonenberg_work>
I get as close as i can on my ciscos by setting unused ports to vlan 99
<rqou>
otherwise ports can pretend to look like access ports
<azonenberg_work>
and not putting anything but other unused ports on 99
<azonenberg_work>
and putting bpduguard and forced access mode on access ports
<rqou>
on my switch i still need to test this, but i have unused ports set to not be a member of any vlans and to have ingress filtering enabled
<rqou>
i'm not sure how BPDUs can be exploited?
<azonenberg>
That's just a sanity check against a switch being plugged into a port where i dont expect one
<azonenberg>
its more to protect against network loops
<azonenberg>
since i have portfast on and it isnt running spanning tree
<rqou>
i've just left MSTP enabled for now
<azonenberg>
if it sees any bpdus that means there's a loop
dingbat has joined ##openfpga
<azonenberg>
STP is fine between swtiches
<rqou>
it's unfortunately pretty chatty
<azonenberg>
STP on access ports means that you have a ~30 sec delay between when you plug something in and when it routes anywhere
<azonenberg>
So i do portfast, which starts up in access mode immediately (not trying to converge STP)
<rqou>
hmm i think the default bridge forwarding delay on my switch is lower
<azonenberg>
But this also means you can get a network loop if you plug two ports into each other by accident
<azonenberg>
So the way to solve that is to send BPDUs out those ports
<azonenberg>
and if you ever get one back, shut the port down
<azonenberg>
as a side effect it happens to lock out switches running STP on the port
<azonenberg>
but you can of course easily use a dumb switch or turn STP off, its not for security
<azonenberg>
its just an idiotproofing measure
<rqou>
hmm on my switch the forwarding delay is only 15s
<azonenberg>
i forget the number
<azonenberg>
"annoyingly long" :p
<rqou>
sure
<azonenberg>
my boxen are up in ~1 sec including getting an IP
<azonenberg>
and if i probed for routers explicitly it'd be in the tens of ms probably
<rqou>
yeah my vm software bridge has a forwarding delay of 0
<rqou>
because software bridges can't? have any loops
<rqou>
unless you really messed up?
<azonenberg>
makes sense
<rqou>
i'm still working on flushing out all the random problems in the network right now
<rqou>
btw whoever works on the meraki firmware is actually pretty good at testing "weird crap"
<rqou>
e.g. its RSTP interops with my LB4M's MSTP correctly
<rqou>
it sees the LB4M's CDP packets
<rqou>
it even accepts the random 8G fibre channel SFP dig gave me :P
<rqou>
and it accepts the fs.com 1g/10g dual rate SFPs
m_w has joined ##openfpga
<davidc___>
"rqou: because softrware bridges can't have any loops" - you've never met our devs
<rqou>
wait how?
<davidc___>
rqou: VMWare workstation vSwitches will happily add as many nic's on a vm as you want to a single network interface
<davidc___>
rqou: then you accidentally bridge the wrong two interfaces in the guest
<davidc___>
rqou: Oh, and the vmware vswitch hard drops STP packets....
<rqou>
wtf
<davidc___>
so one's real network infrastructure never sees the loop; only a packet cannon.
<rqou>
yeah, but assuming the real network can handle that, that becomes just your problem :P
<rqou>
also, i don't know why anybody would ever use the vmware vswitch as opposed to linux kernel bridging
<davidc___>
rqou: well, given that it turns a single broadcast packet into 1GB line-rate repeats of that same packet....
<rqou>
but the real switch can either a) just police/shape down to what you're provisioned for or b) realize that those packets don't go anywhere and drop them
<rqou>
or even c) activate storm control and kick you off
<davidc___>
rqou: yes; the solution was a mix of a) and c)
<davidc___>
(for $reasons, neither alone was helpful)
<rqou>
when i was at broadcom the lab area's top of rack switches explicitly had storm control because too many people made an oops while testing
<rqou>
:P
<rqou>
wow i'm so used to promiscuous mode not working that i get surprised when it does work :P
talsit is now known as not_listening
not_listening is now known as talsit
<cr1901_modern>
Are Artix-7 and Spartan-6 LUTs comparable?
<cr1901_modern>
LUT arch*
fpgacraft2_ has joined ##openfpga
wolfspraul has joined ##openfpga
kiboneu_ has joined ##openfpga
Spida_ has joined ##openfpga
rah_ has joined ##openfpga
felix_ has quit [Ping timeout: 255 seconds]
Spida has quit [Ping timeout: 255 seconds]
kiboneu has quit [Ping timeout: 255 seconds]
wolfspra1l has quit [Ping timeout: 255 seconds]
rah has quit [Ping timeout: 255 seconds]
felix_ has joined ##openfpga
fpgacraft2 has quit [Ping timeout: 255 seconds]
Spida_ is now known as Spida
fpgacraft2_ is now known as fpgacraft2
amclain has quit [Quit: Leaving]
<dingbat>
cr1901_modern: I believe you are looking for UG384 and UG474. What are you looking to compare?
<l0ser>
i'm going to connect to a UART port on a cable modem of mine however i havent yet bought a uart-usb bridge. what voltage is the uart port most likely to be?
<rqou>
3.3v or 1.8v?
<l0ser>
right. so i would then need a separate bridge to try out for each voltage?
<dingbat>
cr1901_modern: from a very brief read, they are very similar: six inputs, two outputs, for each of the four LUTs in a slice.
<l0ser>
i cant seem to find a 'universal' usb-uart bridge
<cr1901_modern>
dingbat: In short, I wanted to compare Artix 15 to Spartan 9. I think the numbers are directly comparable
<cr1901_modern>
unlike say, the XS3C200 vs LX9 (which I did a naive calculation some time ago: XS3C200 is about 4/9s the size of an LX9)
<cr1901_modern>
Erm, Artx 7 15 to Spartan 6 LX9 lol
<dingbat>
"numbers" meaning...? If you mean LUT size, yes, it seems they have the same LUT arch. But that doesn't mean they have the same CLB arch. For instance, Artix 7 doesn't have SLICEXs like the Spartan 6
<dingbat>
However, the SLICELs are very similar (might be the same)
<rqou>
apparently wireshark has a dissector for "world of warcraft"
<rqou>
but it's not working for overwatch
<cr1901_modern>
dingbat: Numbers i.e. 9 vs 15 or 200 vs 9
<dingbat>
cr1901_modern: i mean, "numbers" of what?
<dingbat>
numbers of CLBs?
<cr1901_modern>
Oh, the number of Slices
<dingbat>
Well, from the respective tables: 7A15T: 16.64k cells, 2.6k slices, 20.8k CLB FFs; 6SLX9: 9.15 k cells, 1.43k slices, 11.4k CLB FFs. And yeah, most of the slices are the same, so the 7A15 is a fair bit larger
<cr1901_modern>
Perfect. I'm thinking about doing an Artix board. Emphasis *thinking*. But I've never done BGA, and Artix is expensive. My designs fit into an LX9.
<cr1901_modern>
Maybe I'll upgrade to LX16 to force myself to do BGA design
<rqou>
herp derp, networks with no default gateways are *weird*
<dingbat>
rqou: what a coincidence. Just spent 20mins wondering why npm was misbehaving. Turns out my raspi decided a default gateway of 0.0.0.0 was a good idea
<rqou>
my situation was even more annoying:
<rqou>
client --> router --> switch --> box fails
<rqou>
but client2 --> switch --> box works
<rqou>
and router --> switch --> box works
<rqou>
and client --> router works
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
<dingbat>
yeowch
<rqou>
yeah what happened in my situation was that pings would get all the way to "box"
<rqou>
and then "box" would say "i don't know what this address is, but it's not on my subnet"
<rqou>
and silently drop replies
digshadow has joined ##openfpga
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
<nats`>
<azonenberg> and any time thermal expansion and wind added up wrong, i went down <= no need for that :D
<nats`>
we have some example of DSL line working with one of the two wire totally removed :D
<rqou>
solution: stop using dsl :P
<azonenberg>
lol
<azonenberg>
nats`: well i was going to do more work on FPGA stuff this evening
<azonenberg>
After a nice romantic dinner with $WIFE
<nats`>
:D
<nats`>
but you had better things to do ? :D
<nats`>
like bulding a mini azonenberg :p
<azonenberg>
Lolol
<azonenberg>
You're not supposed to do that right after you eat, all the bouncing around when you're full? not fun
<azonenberg>
No, I ended up getting a 911 call and running out to the next town to find a missing grandfather who had wandered off
<rah>
although, that says "Communications Signal Analyzer" rather than "Oscilloscope"
<rah>
"CROs were later largely superseded by digital storage oscilloscopes (DSOs) with thin panel displays, fast analog-to-digital converters and digital signal processors. DSOs without integrated displays (sometimes known as digitisers) are available at lower cost and use a general-purpose digital computer to process and display waveforms."
<nats`>
they show the simplest form of acquisition path you can made to have half decent measure
<rah>
nats`: how have you determined that there is no filtering on this OpenScope?
<rah>
let me rephrase that
<rah>
nats`: they haven't released the schematics yet so can't say there's no filtering
<rah>
there is an amplifier at least
<rah>
they say so
<rah>
they don't say anything about input filtering, either way
<nats`>
we will laugh a lot
<nats`>
they seem to use pic32 adc
<nats`>
:D
<nats`>
\o/
<nats`>
dude you should back it and we will play :D
<nats`>
ah and it's a half hidden campaign for digilent
<nats`>
TROLOLOLO please put some money on it :D
<rah>
err. "half hidden"?
<rah>
I'm going to dismiss your objections
<nats`>
it's digilent they don't need a dickstarter campaign it's just a way to make buzzing advertisement
<rah>
I think it's likely that there are many poorly designed DSO scopes on the market at the cheap end
<nats`>
it'll be sold 99$ oO
<rah>
but I don't think Digilent is like one of the cheap Chinese DSO kit makers where they omit an input filter for the ADC
<rah>
a filter is a necessity for sampling
<rqou>
nats`: opinions on the novena oscilloscope design?
<rah>
I think you just don't like this campaign and are trying to find reasons to reject it, rather than disliking it because you've found reasons to reject it
<nats`>
rah if you say so feel free to think that
<nats`>
I' played with their previous all in one tool
<rah>
nats`: I don't need your permission to think that, thankyouverymuch :-)
<rah>
"Set non-default values for router advertisements sent via an interface. The priority field for the router may be altered from the default of medium with eg --ra-param=eth0,high."
<rqou>
huh, missed that
<rqou>
it doesn't have the magic keyword of "preference" :P
<rqou>
but wow the author of dnsmasq thought of everything
<rqou>
except its multi-vlan handling is still a bit borked
<rqou>
it will forget leases for clients on multiple vlans at the same time
<rah>
I'm presuming the "priority field" is the "router preference" you're looking for
<rah>
I can't imagine there would be two mechanisms for the same thing in router advertisements
<rqou>
it is, but my dnsmasq isn't new enough to have that option :P
<rah>
alas
<rqou>
and apparently i can raise preferences to high but not drop them to low
<rqou>
because RAs override it?
<rqou>
no wait, it's there
<rqou>
ok, maybe i don't understand how this is supposed to work
m_t has joined ##openfpga
<rqou>
so for ipv4 i can just change the route metric, but apparently on ipv6 that isn't even a thing i can do
<rqou>
trying to change pref somehow causes the ip command to lose the gateway
massi has joined ##openfpga
<rqou>
also, somehow not all of my interfaces come up when i ifup eth2
<rqou>
they just magically stay down
<rqou>
f*ck it i'll leave it like this and just disable receiving RAs on the interfaces i really don't want to use :P
<rqou>
anyone know what the correct way to configure this is?
<rqou>
basically i have a router with multiple vlans, some of which don't have access to the internet
<rqou>
now i want to connect a client to both vlans
<rqou>
obviously, traffic to the internet needs to go via the vlan that does have access
<rqou>
on ipv4 i just set the metric
<rqou>
on ipv6 apparently this is a lot harder
SpaceCoaster has joined ##openfpga
<rqou>
apparently even disabling router advertisements doesn't fix this
<rqou>
blargh I'll just delete the route in post-up
<rqou>
maybe that'll work?
<rqou>
nope, races with setting the default route
<rqou>
ah accept_ra_defrtr that's what I want
<rqou>
nope, apparently that doesn't help either
promach has quit [Quit: Leaving]
<nats`>
jn__ wants the old altera back <= +10000000000000000000
<nats`>
I'm a xilinx user but this intel shit in the fpga world can only make it worse
scrts has quit [Ping timeout: 252 seconds]
kuldeep has quit [Remote host closed the connection]
<rqou>
hmm apparently accept_ra_defrtr works except that /etc/network/interfaces is super full of race conditions