<mrnuke_>
russell--: The label on the bottom of mine says "HW v1.0.0". What does your unit say?
<mrnuke_>
russell--: also, if you wish to change boot partition from openwrt, you can do "fw_setsys bootpartition 1"
<mrnuke_>
russell--: I'm kind of smirking that someone finally got to use the pin 16 trick :D
<russell-->
mrnuke_: after the pin16 trick, it whines a little and claims to be erasing some blocks of something from address A to adress B or something
<russell-->
Erasing SPI flash...II: Erasing 4096 bytes from b5000000... 100%
<russell-->
and:
<russell-->
Erasing SPI flash...II: Erasing 4096 bytes from 00090000... 100%
<russell-->
Writing to SPI flash...II: Writting 4096 bytes to 00090000... 100%
* russell--
looks for the label
<russell-->
the sticker on the bottom of the case says: "HW: v 3.0.0", but the board silkscreen says "EWS2910Pv3 / 7016A269500u / VER: 1.00" where / indicates newline
<russell-->
has anyone disassembled or otherwise obtained source code for the u-boot that might suggest a less electrical way of getting a u-boot prompt?
<russell-->
i see two rtl8231 chips and an rtl8238b on the board
<russell-->
there is also a populated four pin header labelled j10
<russell-->
ooh, and another 28 pin part labelled ASKT<mumble> (the last bit is covered with a blob of green paint)
<mrnuke_>
Best thing to do is take this to the rtl838x thread, and ask there. We'll need to reverse-enginerd the protocol
<mrnuke_>
If there is a header next to the mystery chips, then put a logic analyzer on it and see what comes out. Is it UART ? Is it I2C ?
<mrnuke_>
For example, in the ews2910p image I shared earlier, J7 -- above the leftmost ethernet transformer-- is the header that I used to probe the PoE UART (image is here https://github.com/mrnuke/openwrt/wiki/Engenius-EWS2910P)
<russell-->
my guess is that the E230G8 is the microcontroller
<mrnuke_>
I agree
<mrnuke_>
svanheule: ^^^^^^ This is an interesting new hardware challenge
<russell-->
i'm recharging the battery for my "good" camera to get a better board sized image
<mrnuke_>
No rush. I'm going to go recharge my batterries here. It's about that time of night :p
<nick[m]1234>
What do you do when having "doesn't start on an erase/write block boundary"? I used the original avm layout
valku has quit [Remote host closed the connection]
MaxSoniX has joined #openwrt-devel
Misanthropos has quit [Ping timeout: 480 seconds]
MaxSoniX has quit [Remote host closed the connection]
MaxSoniX has joined #openwrt-devel
goliath has joined #openwrt-devel
Tapper has joined #openwrt-devel
Misanthropos has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
srslypascal is now known as Guest7076
srslypascal has joined #openwrt-devel
<jow>
question for the native english speakers: does "flashing" mean that something is continuously illuminated or that it is blinking?
<jow>
context is that I look for an appropriate phrase to describe the "invert" option of a heartbeat LED trigger
<jow>
nvm, found it. glowing/shining/lighted would be more approrpaite words I guess
<jow>
s/lighted/lit/
Guest7076 has quit [Ping timeout: 480 seconds]
winternull_ has joined #openwrt-devel
goliath has joined #openwrt-devel
robimarko has joined #openwrt-devel
mangix_ has joined #openwrt-devel
mangix has quit [Ping timeout: 480 seconds]
winternull has quit [Ping timeout: 480 seconds]
danitool has joined #openwrt-devel
<f00b4r0>
jow: flashing means blinking. I would describe inverted heartbeat as "lit with brief interruptions" or in more technical terms as "flashing with long duty cycle" :)
<Harm_>
nick[m]1234: maybe disable pci-e for now in the device tree? As the log stops there
mangix_ has quit []
mangix has joined #openwrt-devel
<russell-->
also flash on a camera, a brief bright light
<russell-->
initial attempts with the logic analyser were not successful
<russell-->
probably need to start with an oscilloscope
Tapper has quit [Ping timeout: 480 seconds]
goliath has quit [Quit: SIGSEGV]
goliath has joined #openwrt-devel
bluew has quit [Ping timeout: 480 seconds]
Tapper has joined #openwrt-devel
robimarko_ has joined #openwrt-devel
<stintel>
f00b4r0: hah, I jinxed it :P my main m300 just rebooted
<stintel>
not sure if it was kernel panic or watchdog reset, I have a serial console attached and had screen running on it, but the box running screen crashed earlier this week and did not start the screen again afterwards :/
<stintel>
so I don't have logging, again
<stintel>
goddamnit
robimarko has quit [Ping timeout: 480 seconds]
<stintel>
does anyone know if there are syslog daemons that can use serial port for input ?
<stintel>
so far my search has not yielded any results, which seems completely unthinkable
<f00b4r0>
so the router crashed and the box monitoring the router also crashed ? Seems like you have some stability issues :->
<stintel>
last time I had a btrfs deadlock introduced in an lts kernel bump
<stintel>
seriously need to reconsider running btrfs
<f00b4r0>
My understanding of btrfs is that it's a /killer/ fs :-3
<stintel>
but this time I actually suspect it was memory pressure
<stintel>
and zfs ... with its spl ...
<stintel>
everything is just shit
MaxSoniX has quit [Remote host closed the connection]
<stintel>
and the alternative is a filesystem without checksumming :(
<f00b4r0>
i'm running ZoL fine (in truenas scale)
<f00b4r0>
since the codebase merged with the bsd implementation it seems to have gotten quite robust
<stintel>
let's hope bcachefs makes it in the kernel before end of year
<f00b4r0>
anyhow, for your serial woes, redirecting ttyS0 to some file seems like an easy workaround
<stintel>
yeah but I can't wrap my head around the fact that no syslog daemon supports this natively
<f00b4r0>
well I'm guessing the need for it may not be quite obvious given how "trivial" it is to do without
<stintel>
the trivial way is still a hack, imo
<stintel>
anyway
<Habbie>
the loggers that can read from /dev/klog surely could read from something else?
<f00b4r0>
meanwhile it looks like i'll have to pick nbd's brain on yet another mind boggling mt7915 issue
<stintel>
at least my wifi is stable :P
<f00b4r0>
;)
<robimarko_>
f00b4r0: You always find some crazy edge cases
<stintel>
I should duplicate my strongSwan roadwarrior config to the backup m300
<f00b4r0>
yeah, it seems i have a talent for breaking things :)
<stintel>
I probably wouldn't even have noticed the main m300 going down then :P
<nbd>
f00b4r0: what kind of issue?
MaxSoniX has joined #openwrt-devel
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
<f00b4r0>
nbd: not sure how to describe it. Basically, in a setup with two Yuncore AX820 which use a bridge-vlan setup, if e.g. the LAN network in on a non-tagged VLAN, a client roaming from one AP to the next will experience a blackout that lasts a couple minutes. If the LAN network is moved to a tagged VLAN, the problem disappears
<f00b4r0>
nbd: I will try to collect more relevant info
<f00b4r0>
(tagged/untagged is for the ethernet link to the main router / dhcp server, of course)
<stintel>
you're not running bridger, are you ?
<f00b4r0>
no; this is pure bridge-vlan setup
dvn- is now known as dvn
<Slimey>
stintel i got the adtran 6040 waps in :D maybe some internal pics soon :P
<stintel>
Slimey: do you know what platform they're based on ?
<Slimey>
qca
<Slimey>
ipq something i have more info soon
borek has joined #openwrt-devel
valku has joined #openwrt-devel
rua has quit [Remote host closed the connection]
rua has joined #openwrt-devel
Misanthropos has quit [Ping timeout: 480 seconds]
xback has quit [Remote host closed the connection]
<f00b4r0>
hmm
<f00b4r0>
if I tcpdump the bridge vlan, I do not see ICMP traffic going through it, neither on the 802.1q interface related to the LAN vlan, although I do see the ICMP traffic on the wireless interface
<f00b4r0>
that seems... abnormal
<f00b4r0>
and the RTT times are all over the place too
* f00b4r0
scratches head
* f00b4r0
suspects an offloading thing
goliath has quit [Quit: SIGSEGV]
Misanthropos has joined #openwrt-devel
<f00b4r0>
hmm; on the AX820, if I tcpdump the "physical" DSA interface, on the vlan that should be untagged, the frames have the vid tag
<f00b4r0>
s/the/some/
<f00b4r0>
oh i see. Seems to be incoming frames. I guess that's a side effect of vlan-bridge which was confusing me.
<f00b4r0>
still doesn't explain why some frames seem to disappear, DHCP replies in particular
minimal has joined #openwrt-devel
goliath has joined #openwrt-devel
cmonroe has joined #openwrt-devel
robimarko_ has quit [Quit: Leaving]
Tapper has quit [Ping timeout: 480 seconds]
<f00b4r0>
is there a way to meaningfully run tcpdump on the DSA master interface, with some level of decoding? I'm trying to understand "where" the frames disappear
danitool has joined #openwrt-devel
Tapper has joined #openwrt-devel
robimarko has joined #openwrt-devel
borek has quit [Ping timeout: 480 seconds]
<russell-->
mrnuke_: to confirm, you are telling me that on HW v1.0.0 the PoE works?
<russell-->
fwiw, looking at the circuit board last night, there is an i2c optoisolator between the microcontroller and the rtl8238b
<mrnuke_>
russell--: v1 has a different PoE controller
<mrnuke_>
It's not an 8238b. It's some broadcom stuff (I forget the exact PN)
<mrnuke_>
Yes, on v1, realtek-poe works.
noahm has joined #openwrt-devel
cbeznea has quit [Quit: Leaving.]
MaxSoniX has quit [Quit: Konversation terminated!]
kabel has quit [Read error: Connection reset by peer]
<russell-->
mrnuke_: thanks
<russell-->
i'm working with someone hoping to use these switches, we both purchased from the same source and i got the v3, they got v1
<russell-->
seems like the vendor firmware is the same for both versions? so it must distinguish what hardware it's talking to.
<mrnuke_>
`cat /sys/kernel/debug/gpio` ?
<mrnuke_>
Ooh, nevermind. That won't work. Need to export the GPIOs first
<mrnuke_>
` for y in $(seq 451 511); do echo "$y" > /sys/class/gpio/export; done`
<mrnuke_>
russell--: Mine does the same -- no huge surprise here. I was hoping maybe uboot is updated for the "newer' PSE chip
kabel has joined #openwrt-devel
<russell-->
so, v3 has one row of populated headers, the lower row is unpopulated
<russell-->
in respose to an rtk poe probe, i'm seeing nothing on any of the populated headers
<russell-->
pin 1 seems to be vcc, pin 2 sits at 3.3v, pin 3 sits at 0v, pin 4 seems to be ground
<russell-->
also seeing nothing on the unpopulated row of pins
<russell-->
fwiw, i did an i2cdetect on bus 0 in openwrt and saw nothing
<russell-->
has anyone tried to extract the filesystem from the vendor firmware?
<mrnuke_>
russell--: `binwalk -e`
<mrnuke_>
also, if probing headers, probe them when running the vendor FW. The u-boot command obviously doesn't work, so it tells us absolutely nothing