1

(10 odpowiedzi, napisanych Oprogramowanie / Software)

Poniżej informacja gdzie tkwi problem. Wystarczy zmienić poziom logowania w konfiguracji i serwer działa jak należy. Poniżej info:

Cytat z ticket'u "https://dev.openwrt.org/ticket/10273":
"...
I tracked this bug down to the 'LogLevel debug' entry in the httpd.conf file. If you set it to 'LogLevel notice' everything works as expected.

Cheers.
comment:9 Changed 39 hours ago by X…

confirm apache 2.2.15 working with "LogLevel error"
thank you!"

2

(10 odpowiedzi, napisanych Oprogramowanie / Software)

Zainstalowałem. Jednak brakuje mi w nim pewnych funkcji Apache. Np. możliwości "proxy'fikacji" połączeń.
Chodzi o to, że Apache ma być zainstalowany na routerze z publicznym adresem IP. Ma być frontendowym serwerem HTTPS. Router na podstawie tego co wpiszę po adresie jego www (np. https://host_routera/cos_tam/) przekieruje (nie redirect, a funkcja proxy, jest różnica) ruch do odpowiedniego serwera w jego sieci LAN niedostępnego z zewnątrz. Niby lighttpd też ma podobną funkcję, ale działa inaczej (generuje to problemy z dostępem do niektórych usług www). Krótko mówiąc Apache'em można łatwiej, szybciej i przyjemniej.

3

(10 odpowiedzi, napisanych Oprogramowanie / Software)

Czy starsza wersja (z innego repo) ma szansę zadziałać? Tak jak wspomniałem, wcześniej mi chodziło (nie pamiętam niestety wersji OpenWRT).

4

(10 odpowiedzi, napisanych Oprogramowanie / Software)

big_smile Dzięki serdeczne. W takim razie trzeba zgłosić.

5

(10 odpowiedzi, napisanych Oprogramowanie / Software)

opkg install apache
apachectl start
tail -f /var/log/error_log
Mógłbyś? smile

6

(10 odpowiedzi, napisanych Oprogramowanie / Software)

Cezary, możesz potwierdzić, że problem występuje również u Ciebie? Chodzi o czysta instalacje i odpalenie. Pytam, bo brak jakichkolwiek świeżych informacji u wujka G na  temat podobnych sytuacji u innych.

Problem w OpenWrt Attitude Adjustment 12.09 (r33948).

Komenda: apachectl start

Poniżej komunikat z error_log'a:
"...
[Mon Jan 14 10:13:59 2013] [notice] Apache/2.2.15 (Unix) mod_ssl/2.2.15 OpenSSL/1.0.1c configured -- resuming normal operations
[Mon Jan 14 10:13:59 2013] [info] Server built: Aug 26 2012 14:31:49
[Mon Jan 14 10:13:59 2013] [debug] prefork.c(1013): AcceptMutex: sysvsem (default: sysvsem)
[Mon Jan 14 10:14:00 2013] [notice] child pid 3999 exit signal Segmentation fault (11)
[Mon Jan 14 10:14:00 2013] [notice] child pid 4000 exit signal Segmentation fault (11)
[Mon Jan 14 10:14:00 2013] [notice] child pid 4001 exit signal Segmentation fault (11)
[Mon Jan 14 10:14:00 2013] [notice] child pid 4002 exit signal Segmentation fault (11)
[Mon Jan 14 10:14:00 2013] [notice] child pid 4003 exit signal Segmentation fault (11)
[Mon Jan 14 10:14:02 2013] [notice] child pid 4004 exit signal Segmentation fault (11)
[Mon Jan 14 10:14:03 2013] [notice] child pid 4006 exit signal Segmentation fault (11)
[Mon Jan 14 10:14:03 2013] [notice] child pid 4007 exit signal Segmentation fault (11)
[Mon Jan 14 10:14:04 2013] [info] server seems busy, (you may need to increase StartServers, or Min/MaxSpareServers), spawning 8 children, there are 4 idle, and 4 total children
..."

Na tą chwilę nie ma PHP, więc błędy nie dotyczą tamtejszych modułów.

Być może dotyczy to: https://dev.openwrt.org/ticket/10273 .

Czy ktoś miał podobne doświadczenia i co ważniejsze udało mu się rozwiązać problem?

PS Przysiągłbym, że jakiś czas temu, na tej samej platformie problemu z Apache'm nie miałem. Stawiałem chyba LAMP.

8

(18 odpowiedzi, napisanych Oprogramowanie / Software)

1. W jakim pakiecie znajdę "arecord"?
2. libffmpeg-full już nie jest dostępny?

9

(35 odpowiedzi, napisanych Oprogramowanie / Software)

Odgrzewamy.
@florekk korzystasz z wejść zrobionych na DS2408? Najwygodniej byłoby korzystać z właściwości "set_alarm". Ustawić go na 133333333, które to ustawienie spowoduje, że 1 a dowolnym latch'u spowoduje pojawienie się DS'a w alarm/. To z kolei może być wyzwalaczem do odczytania stanu faktycznego (słowa bitowego) z DS'a. Było by szybciej i wydajniej. Problem w tym, że ustawienie set_alarm na w/w wartość nie jest możliwe. Znów wracamy do problemu bibliotek. Masz na to jakieś rozwiązanie?

Mam problem z rozłączaniem się (w sensie "od magistrali USB") modemu 3g. Zdarzenie następuje zazwyczaj w momencie "wzmożonej aktywności" modemu (np.: transmisja danych, lub wysyłanie SMS).

U mnie cała instalacja przedstawia się następująco: RSPro + 2xHUB USB + karta SD (ext-root) + modem Huawei E182E + 2xHDD + 2xFT232 + pl2303 + karta muzyczna USB.

Wydawało już mi się, że ustabilizowałem "napięciowo" całą instalację, bo...

RSPro ma swój własny (całkiem mocny) zasilacz. Każdy z (2ch) HUB'ów jest aktywny. W pierwszym HUB'ie mam: modem + karta SD (ext-root), w drugim: 2x HDD, 2xFT232, 1xPL2303, karta muzyczna. W powodu dużego poboru prądu (tu mowa głównie o modemie i dyskach), zamiast oryginalnych zasilacz (500mA) zastosowałem wyjście 5V zasilacza ATX (już zresztą wcześniej zamontowanego na potrzeby: zasilania kamer IP, podświetlenia LED domu, zasilenia węża świetlnego w łazience, etc.). Dodatkowo w przewodach USB HUB'ów odłączyłem styk +5V (gdzieś czytałem, że zasilania z różnych źródeł mogą na siebie negatywnie oddziaływać). Obciążalność złącza 5V w takim zasilaczu jest gdzieś w granicy 20A. Zapas więc jest.
Okazuje się, że to nie wystarczyło. Modem nadal na ułamek sekundy "odpina się" od USB.

Może macie pomysły co jeszcze poprawić żeby ustabilizować jego pracę?

Z tego co pamiętam to SDIO jest jakoś późno "widziane" przez system i jest problem ze startem ex-root'a (mogę się mylić, to było jakiś czas temu). Tak czy owak, to na inny wątek. Zastanawiam sie jak ustabilizować prace modemu. Gdzieś czytałem, że czasem zewnętrzny zasilacz może nie pomagać, a komplikować sprawę.

Nie bardzo rozumiem. Wiem, że dobrze by było żeby było stabilnie, ale niestety nie jest. RSPro mam mocny zasilacz i wydawało by się, że w połączeniu z aktywnym HUB'em (HUB'ami) będzie grał jak trzeba. Okazuje się, że nie. Miałeś doświadczeni z RSPro? W głównej mierze chodzi mi o wykorzystanie złącza SDIO. Ja z tym miałem problemy (niestabilna praca exroot'a).

HUB'y są oczywiście aktywne. Każdy (z 2-ch) ma swoje zasilanie, choć kabelki trochę cienkie.
Rozumiem, że to nie jest typowy problem OpenWRT i (niektórych modeli) modemów i przyczyn mam szukać gdzie indziej? Chyba, że coś jest nie tak z samym RSPro. hmm
PS Czy zainstalowane jednocześnie pakiety ehci i ohci kolidują ze sobą?

Wszystko pięknie. Udało się skonfigurować/oskryptować konfigurację modemu, 2 przejściówek FT232 i jednej PL2303. Wykrywa i przypisuje interfejsy jak trzeba. Dzięki za sugestię.
Tak na marginesie. Wiadomo dlaczego rozłącza modem, a tym samym wszystko co jest podpięte na USB? To kwestia modelu modemu? Ilości urządzeń i obciążenia?
O ile sam problem rozłączania urządzeń na USB nie jest wielkim problemem, to (czasem występujące) skutki uboczne już bardziej. Te skutki to np brak możliwości "dostania się" do interfejsu UI modemu, wymagające restartu. Restartów wolałbym unikać ze względu na uruchomiony ciągły monitoring posesji, monitoring temperatur pomieszczeń, pieca, sterowanie (OWFS). Poza tym takie "zwieszenie" UI w modemie powoduje, że gnokii nie odbiera i nie wysyła SMSów. To już spory kłopot.
Cezary masz jakieś pomysły na rozwiązanie tego problemu?

Wyłączenie "bwmon" pomogło (co do rmmod'a).
W sumie irytujący objaw, ten rozłączający się modem. Przesuwa się wtedy na inne interfejsy. Siada komunikacja i inne usługi (1Wire, etc. - Wszystko co chodzi po USB). Dałem już go na osobnym aktywnym HUB'ie.
Macie pomysł jak to poprawić?

Czy ten moduł poprawia czas systemowy? Nie jest to rolą klienta NTP?

Nie daje się skubany...
rmmod: can't unload 'ipt_bandwidth': Resource temporarily unavailable
Parametr -f też nie działa.
Jakieś sugestie?

A jak usunąć go trwale? rmmod usuwa go do restartu. Mam wrzucić rmmod'a w rc.local?

Dzięki. Spróbuję.

Poza sytuacją opisaną powyżej nie zauważyłem innego konkretnego "powodu" restartu WAN'u. W większości przypadków restart następuję po w/w komunikacie.
Usunięcie w/w modułu nie spowoduje, dodatkowej "dysfukcji" jakichś innych w OS?

Cezary, w logach mam:
ipt_bandwidth: backwards time shift detected, adjusting
usb 1-1.4.2: USB disconnect, address 12
option: option_instat_callback: error -143
option1 ttyUSB2: GSM modem (1-port) converter now disconnected from ttyUSB2
option 1-1.4.2:1.0: device disconnected
option1 ttyUSB3: GSM modem (1-port) converter now disconnected from ttyUSB3
option 1-1.4.2:1.1: device disconnected
option1 ttyUSB4: GSM modem (1-port) converter now disconnected from ttyUSB4
option 1-1.4.2:1.2: device disconnected
usb 1-1.4.2: new high speed USB device using ar71xx-ehci and address 13
usb 1-1.4.2: configuration #1 chosen from 1 choice
option 1-1.4.2:1.0: GSM modem (1-port) converter detected
usb 1-1.4.2: GSM modem (1-port) converter now attached to ttyUSB2
option 1-1.4.2:1.1: GSM modem (1-port) converter detected
usb 1-1.4.2: GSM modem (1-port) converter now attached to ttyUSB3
option 1-1.4.2:1.2: GSM modem (1-port) converter detected
usb 1-1.4.2: GSM modem (1-port) converter now attached to ttyUSB4

Za każdym razem gdy "poprawia" mi czas, rozłącza mi modem. Przy próbie usunięcia mam zależności do:
* print_dependents_warning:    iptables-mod-bandwidth
* print_dependents_warning:    libiptbwctl
* print_dependents_warning:    gargoyle-firewall-util

Czy można w/w pakiet usunąć bez większych szkód? Cyba, że można go np. czasowo wyłączyć dla testów...?

22

(1 odpowiedzi, napisanych Oprogramowanie / Software)

Wywaliłem "libftdi" (zaplątało się podczas konfiguracji). Już jest OK.

Witam.

Ostatnio dotarłem do pewnego punktu w budowanie swojej infrastruktury 1W, w którym to nie działają dwie przejściówki pasywne PL2303. Kupiłem więc dwie przejściówki FTDI. Teraz nie mogę uruchomić nawet jednej.
Czy komuś się udało uruchomić OWFS'a na takiej przejściówce?

Ja dostaje komunikaty:
# owfs -d /dev/ttyUSB3 /mnt/1-Wire/OWFS --error_level=9
CONNECT: ow_dnssd.c:(82) Zeroconf/Bonjour is disabled since dnssd library isn't found
   CALL: ow_parsename.c:(98) path=[]
  DEBUG: owlib.c:(82) Globals temp limits 0C 100C (for simulated adapters)
  DEBUG: ow_ds9097U.c:(286) Attempt 0 of 3 to initialize the DS9097U
  DEBUG: ow_ds9097U.c:(377) Send the initial reset to the bus master.
  DEBUG: ow_tcp_read.c:(64) attempt 1 bytes Time: 5.000000 seconds
CONNECT: ow_tcp_read.c:(110) TIMEOUT after 0 bytes
  DEBUG: ow_ds9097U.c:(472) Failed first attempt at resetting baud rate of bus master /dev/ttyUSB3
  DEBUG: ow_tcp_read.c:(64) attempt 1 bytes Time: 5.000000 seconds
CONNECT: ow_tcp_read.c:(110) TIMEOUT after 0 bytes
  DEBUG: ow_ds9097U.c:(477) Failed second attempt at resetting baud rate of bus master /dev/ttyUSB3
  DEBUG: ow_tcp_read.c:(64) attempt 1 bytes Time: 5.000000 seconds
CONNECT: ow_tcp_read.c:(110) TIMEOUT after 0 bytes
  DEBUG: ow_tcp_read.c:(64) attempt 1 bytes Time: 5.000000 seconds
CONNECT: ow_tcp_read.c:(110) TIMEOUT after 0 bytes
  DEBUG: ow_tcp_read.c:(64) attempt 1 bytes Time: 5.000000 seconds
CONNECT: ow_tcp_read.c:(110) TIMEOUT after 0 bytes
  DEBUG: ow_tcp_read.c:(64) attempt 1 bytes Time: 5.000000 seconds
CONNECT: ow_tcp_read.c:(110) TIMEOUT after 0 bytes
  DEBUG: ow_ds9097U.c:(472) Failed first attempt at resetting baud rate of bus master /dev/ttyUSB3
  DEBUG: ow_tcp_read.c:(64) attempt 1 bytes Time: 5.000000 seconds
CONNECT: ow_tcp_read.c:(110) TIMEOUT after 0 bytes
  DEBUG: ow_ds9097U.c:(477) Failed second attempt at resetting baud rate of bus master /dev/ttyUSB3
  DEBUG: ow_tcp_read.c:(64) attempt 1 bytes Time: 5.000000 seconds
CONNECT: ow_tcp_read.c:(110) TIMEOUT after 0 bytes
  DEBUG: ow_tcp_read.c:(64) attempt 1 bytes Time: 5.000000 seconds
CONNECT: ow_tcp_read.c:(110) TIMEOUT after 0 bytes
  DEBUG: ow_tcp_read.c:(64) attempt 1 bytes Time: 5.000000 seconds
CONNECT: ow_tcp_read.c:(110) TIMEOUT after 0 bytes
  DEBUG: ow_tcp_read.c:(64) attempt 1 bytes Time: 5.000000 seconds
...

lub

# owserver -u -p 4304 --error_level=9
Oct  4 13:22:15 OWFS[18852]: DEFAULT: ow_daemon.c:(144) Entered background mode, quitting.
Oct  4 13:22:15 OWFS[18852]:   DEBUG: ow_daemon.c:(167) main thread id = 1024
Oct  4 13:22:15 OWFS[18852]: CONNECT: ow_avahi_link.c:(72) No Avahi support. Library libavahi-client couldn't be loaded
Oct  4 13:22:15 OWFS[18852]: CONNECT: ow_dnssd.c:(82) Zeroconf/Bonjour is disabled since dnssd library isn't found
Oct  4 13:22:15 OWFS[18852]:    CALL: ow_parsename.c:(98) path=[]
Oct  4 13:22:15 OWFS[18852]:   DEBUG: owlib.c:(82) Globals temp limits 0C 100C (for simulated adapters)
Oct  4 13:22:15 OWFS[18852]: DEFAULT: owlib.c:(205) Cannot open USB bus master

lub

owfs --passive=/dev/ttyUSB3 /mnt/1-Wire/OWFS --error_level=9
CONNECT: owfs.c:(96) fuse mount point: /mnt/1-Wire/OWFS
CONNECT: ow_avahi_link.c:(72) No Avahi support. Library libavahi-client couldn't be loaded
CONNECT: ow_dnssd.c:(82) Zeroconf/Bonjour is disabled since dnssd library isn't found
   CALL: ow_parsename.c:(98) path=[]
  DEBUG: owlib.c:(82) Globals temp limits 0C 100C (for simulated adapters)
  DEBUG: ow_tcp_read.c:(64) attempt 1 bytes Time: 5.000000 seconds
CONNECT: ow_tcp_read.c:(110) TIMEOUT after 0 bytes
  DEBUG: ow_tcp_read.c:(64) attempt 1 bytes Time: 5.000000 seconds
CONNECT: ow_tcp_read.c:(110) TIMEOUT after 0 bytes
  DEBUG: ow_tcp_read.c:(64) attempt 1 bytes Time: 5.000000 seconds
CONNECT: ow_tcp_read.c:(110) TIMEOUT after 0 bytes
DEFAULT: owlib.c:(137) Cannot detect DS9097 (passive) interface on /dev/ttyUSB3.
  DEBUG: ow_serial_free.c:(44) COM_close: flush
  DEBUG: ow_serial_free.c:(46) COM_close: restore
  DEBUG: fuse_line.c:(82) Added FUSE option 0 OWFS
  DEBUG: fuse_line.c:(82) Added FUSE option 1 /mnt/1-Wire/OWFS
  DEBUG: fuse_line.c:(82) Added FUSE option 2 -o
  DEBUG: fuse_line.c:(82) Added FUSE option 3 direct_io
  DEBUG: owfs.c:(121) fuse_mnt_opt=[(null)]
  DEBUG: owfs.c:(123) fuse_open_opt=[(null)]

Dodam, że po wpięciu przejściówki mam w dmesg:
usb 1-1.4.4: new full speed USB device using ar71xx-ehci and address 9
usb 1-1.4.4: configuration #1 chosen from 1 choice
ftdi_sio 1-1.4.4:1.0: FTDI USB Serial Device converter detected
usb 1-1.4.4: Detected FT232RL
usb 1-1.4.4: Number of endpoints 2
usb 1-1.4.4: Endpoint 1 MaxPacketSize 16384
usb 1-1.4.4: Endpoint 2 MaxPacketSize 16384
usb 1-1.4.4: Setting MaxPacketSize 64
usb 1-1.4.4: FTDI USB Serial Device converter now attached to ttyUSB3

W messeges natomiast:
el: usb 1-1.4.4: new full speed USB device using ar71xx-ehci and address 9
el: usb 1-1.4.4: configuration #1 chosen from 1 choice
el: ftdi_sio 1-1.4.4:1.0: FTDI USB Serial Device converter detected
el: usb 1-1.4.4: Detected FT232RL
el: usb 1-1.4.4: Number of endpoints 2
el: usb 1-1.4.4: Endpoint 1 MaxPacketSize 16384
el: usb 1-1.4.4: Endpoint 2 MaxPacketSize 16384
el: usb 1-1.4.4: Setting MaxPacketSize 64
el: usb 1-1.4.4: FTDI USB Serial Device converter now attached to ttyUSB3
modeswitch: 1-1.4.4:1.0: Manufacturer=ELKOM-SERWIS Product=USB_<->_RS232/TTL_EM218 Serial=FTVNG8SN

Będę wdzięczy za pomysły rozwiązania problemu.

Udało się komuś uruchomić 2 takie konwertery?
Jeden działa OK. Jak tylko podepnę 2-gi, pierwszy przestaje działać. Jedyne co widzę w logu po włączeniu 2-go to:
Sep 30 13:18:57 kernel: ------------[ cut here ]------------
Sep 30 13:18:57 kernel: WARNING: at drivers/usb/serial/usb-serial.c:441 0x86d906fc()
Sep 30 13:18:57 kernel: [truncated] Modules linked in: fuse w1_smem w1_ds2760 w1_ds2433 sierra pl2303 option cdc_ether ds2490 ums_usbat ums_sddr55 ums_sddr09 ums_karma ums_jumpshot ums_isd200 ums_freecom ums_datafab ums_cypress ums_alauda usbserial us
Sep 30 13:18:57 kernel: Call Trace:[<80069378>] 0x80069378
Sep 30 13:18:57 kernel: [<80069378>] 0x80069378
Sep 30 13:18:57 kernel: [<8008757c>] 0x8008757c
Sep 30 13:18:57 kernel: [<86d906fc>] 0x86d906fc
Sep 30 13:18:57 kernel: [<86d906fc>] 0x86d906fc
Sep 30 13:18:57 kernel: [<801a60fc>] 0x801a60fc
Sep 30 13:18:57 kernel: [<801a4754>] 0x801a4754
Sep 30 13:18:57 kernel: [<801a8464>] 0x801a8464
Sep 30 13:18:57 kernel: [<801a8e80>] 0x801a8e80
Sep 30 13:18:57 kernel: [<86d90c64>] 0x86d90c64
Sep 30 13:18:57 kernel: [<801a0ddc>] 0x801a0ddc
Sep 30 13:18:57 kernel: [<801a10e8>] 0x801a10e8
Sep 30 13:18:57 kernel: [<800e4d38>] 0x800e4d38
Sep 30 13:18:57 kernel: [<800e14a0>] 0x800e14a0
Sep 30 13:18:57 kernel: [<800897a0>] 0x800897a0
Sep 30 13:18:57 kernel: [<8008afd8>] 0x8008afd8
Sep 30 13:18:57 kernel: [<8008b450>] 0x8008b450
Sep 30 13:18:57 kernel: [<80095d40>] 0x80095d40
Sep 30 13:18:57 kernel: [<8006ed08>] 0x8006ed08
Sep 30 13:18:57 kernel: [<80083378>] 0x80083378
Sep 30 13:18:57 kernel: [<8008185c>] 0x8008185c
Sep 30 13:18:57 kernel: [<800e44fc>] 0x800e44fc
Sep 30 13:18:57 kernel: [<8008456c>] 0x8008456c
Sep 30 13:18:57 kernel: [<80092920>] 0x80092920
Sep 30 13:18:57 kernel: [<800e46b4>] 0x800e46b4
Sep 30 13:18:57 kernel: [<80084638>] 0x80084638
Sep 30 13:18:57 kernel: [<80060988>] 0x80060988
Sep 30 13:18:57 kernel: ---[ end trace e191cf113ea3e33f ]---

25

(20 odpowiedzi, napisanych Oprogramowanie / Software)

CP