J’ai redéveloppé mon site avec React et CodeIgniter grâce à Grok 3, sans presque aucune expérience en React.

Il y a peu, j’ai été forcé de mettre à jour mon site basé sur une version obsolète d’un Framework, Twig/Symfony 3. En débutant l’implémentation avec CodeIgniter, j’ai vite compris que le portage des templates allait être compliqué. Je me suis donc orienté vers quelque chose de plus dynamique et moderne : un frontend en React avec un backend allégé par CodeIgniter. Le hic ? Je n’avais pratiquement aucune expérience en React. Pourtant, en quelques heures et grâce à une poignée de prompts à Grok 3, l’IA de xAI, j’ai réussi cette refonte. Voici comment ça s’est passé.

Une refonte en quelques étapes

J’ai d’abord repensé l’organisation de mon projet. Fini le mélange frontend-backend : j’ai créé deux espaces distincts, un pour le backend et un pour le frontend. Le challenge était de configurer mon serveur local pour que les requêtes API et les pages React aillent là où il faut. J’ai demandé conseil à Grok 3, et en une réponse, il m’a orienté vers une solution simple pour gérer ces redirections, sans que j’aie à me perdre dans des détails techniques.

Pour le backend, migrer de Symfony à CodeIgniter a été assez naturel. J’ai simplifié mes anciennes routes en endpoints légers, et Grok m’a aidé à m’assurer que tout restait cohérent et prêt à alimenter mon futur frontend.

Le frontend React, un défi relevé avec Grok

C’est là que les choses auraient pu se compliquer. Avec presque zéro expérience en React, je partais de loin. Mais Grok 3 a permis de relever le défi. Je lui ai demandé comment démarrer un projet React de zéro et comment en faire une version statique pour mon site. Ses réponses étaient claires, étape par étape, comme un guide patient qui ne me laissait jamais dans le flou. En un rien de temps, j’avais un frontend fonctionnel. Quand j’ai buté sur une erreur où mes données ne s’affichaient pas, Grok a tout de suite compris et m’a donné une astuce simple pour connecter React à mon backend.
Grok a même réussi là où les autres LLM (GPT 4o, Claude 3.5) avaient échoués: calculer le rendu, en React, de mon menu hiérarchique venant d’un json retourné par API. A prompt égal, c’est le seul à avoir réussi.

Quelques ajustements et un résultat bluffant

Tout n’a pas marché du premier coup. A plusieurs reprises j’ai confronté les résultats de Github Copilot, une recherche Google classique et Grok, Grok donne en général la meilleure des réponses avec le moins d’informations. C’est assez bluffant sachant que Github Copilot est totalement intégré à l’IDE contrairement à Grok qui n’a qu’un minimum d’information.

Une transformation éclair malgré mon inexpérience

En quelques heures et une poignée d’échanges avec Grok 3, j’ai métamorphosé mon vieux site Twig/Symfony en une application moderne React + CodeIgniter. Le frontend, presque entièrement conçu avec l’aide de Grok malgré mon manque d’expérience en React, est fluide et réactif. Le backend, lui, reste léger et efficace.

Si vous envisagez de moderniser votre site, même sans être un pro de React ou d’un autre outil, je ne peux que vous encourager à tester Grok 3. Attention toutefois à ce que vous lui transmettez comme information, Grok n’est pas connu pour protéger vos données, exit donc les mots de passe, données privées, etc.

Le site est disponible ici: https://ludovicfavre.ch/

Catégorie : Uncategorized | Laisser un commentaire

Symfony, c’est fini. Vive CodeIgniter !

Pourquoi je quitte Symfony pour CodeIgniter
Après des années à travailler avec Symfony, j’ai pris une décision radicale : abandonner ce framework pour migrer mon site vers CodeIgniter. Mon site actuel repose sur Symfony 3.4, une version qui commence sérieusement à dater. Avec la dernière mise à jour PHP imposée par mon hébergeur, je n’avais plus le choix : il fallait porter le projet vers Symfony 7 pour rester compatible. Mais ce qui devait être une simple mise à jour s’est transformé en galère…

Une migration qui tourne au fiasco
Initialement, je me suis dit : « Faisons simple ». J’ai tenté de migrer un seul composant – une page, un menu ou une API – pour voir comment ça se passait. Spoiler : ça s’est mal passé. Très mal passé. Le gros problème ? L’absence de procédure claire pour passer de Symfony 3.4 à Symfony 7. Les guides officiels sont flous, les étapes manquent de précision, et quand une méthode est dépréciée, on ne te dit pas toujours par quoi la remplacer. Résultat : on se retrouve à tâtonner pour des choses pourtant simples.

Avec les versions 6 et 7, Symfony introduit plusieurs manières de faire la même chose. Génial sur le papier, mais en pratique, ça complique tout. La documentation, qui devrait être une boussole, est devenue une source de confusion. Trop d’options, pas assez de clarté. J’ai passé des heures durant un week-end à essayer de faire fonctionner ne serait-ce qu’une petite partie de mon site. À bout de patience, j’ai décidé de tester une alternative.

Un test pour une solution alternative
Sur un coup de tête, j’ai configuré CodeIgniter dans un nouveau répertoire et l’ai connecté à la base de données pour voir ce que ça donnait. En moins de 30 minutes, j’avais une page fonctionnelle qui servait mes données exactement comme je le voulais. Trente minutes ! Là où Symfony me faisait tourner en rond depuis des heures, CodeIgniter m’a offert simplicité et efficacité. Pas de configuration interminable, pas de documentation alambiquée : juste un framework qui fait le job.

Pourquoi CodeIgniter et pas Laravel ?
CodeIgniter n’est pas nouveau pour moi. J’ai déjà développé plusieurs sites avec, et je connais sa légèreté et sa flexibilité. C’est exactement ce qu’il me faut pour mon site. Laravel, qui est souvent cité comme une alternative moderne à Symfony. Mais pour le type de site que je développe Laravel me semblait « overkill »: Trop de fonctionnalités dont je n’ai pas besoin, alors que CodeIgniter va droit au but.

Symfony n’est pas pour autant un mauvais framework
Ce framework reste une alternative solide pour des projets conséquents, mais il nécessite un suivi régulier avec les mises à jour et des refactorings. Il est possible que je rencontre des problèmes de mises à jour avec CodeIgniter, mais comme ce framework est plus « simple », il sera plus rapide à adapter.


Bye Symfony !
Symfony m’a accompagné pendant longtemps, et j’apprécie sa puissance pour des projets d’envergure. Mais pour mon cas d’usage, il est devenu un frein plus qu’un allié. La migration vers Symfony 7 m’a fait réaliser que je perdais trop à adapter le code au framework, au lieu de construire avec lui. CodeIgniter, lui, répond à mon besoin : simplicité, rapidité, efficacité.

Je tourne la page, mon site va renaître sous CodeIgniter, et je suis impatient de retrouver le faire évoluer une fois la migration effectuée.

Catégorie : Coding, PHP, Uncategorized | Tag | Laisser un commentaire

Dashboard d’énergie sous Home Assistant avec coûts journaliers

Cet article présente la configuration de senseurs de type « pince » (dans le cas présent: via une gateway envoy d’Enphase) afin de calculer:

  • La production journalière
  • La consommation (import et/ou solaire) journalière
  • L’exportation journalière d’énergie (production solaire)

Cette configuration se faisant de manière relativement simple sous Home Assistant, je voulais également calculer le coût quotidien de l’électricité.

Enphase propose déjà la gestion de tarif sur enlighten (leur portail online) mais je voulais avoir la même chose sur Home Assistant afin de ne pas dépendre d’Enphase pour stocker et consulter ces données.

Cet article traite le cas où les pinces sont branchées en consommation et en production. Il faut donc calculer la puissance produite et consommer. A cet effet, il faut déclarer deux senseurs dans configuration.yaml :


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
template:
  - sensor:
        name: Grid Import Power
        state_class: measurement
        icon: mdi:transmission-tower
        unit_of_measurement: W
        state: >
            {{ [0, states('sensor.envoy_<id>_current_power_consumption') | int(0) - states('sensor.envoy_<id>_current_power_production') | int(0) ] | max }}
  - sensor:
        name: Grid Export Power
        state_class: measurement
        icon: mdi:transmission-tower
        unit_of_measurement: W
        state: >
            {{ [0, states('sensor.envoy_<id>_current_power_production') | int(0) - states('sensor.envoy_<id>_current_power_consumption') | int(0) ] | max }}

Nous allons également déclarer un senseur pour le tarif heure pleine / heure creuse de la Romande Energie.


1
2
3
4
5
6
7
8
9
10
11
  - sensor:
        name: Tariff Price
        unit_of_measurement: CHF/kWh
        state: >
            {% if is_state('select.energy_meter_tarif', 'hp') %}
                {{ 0.3675}}
            {% elif is_state('select.energy_meter_tarif', 'hc') %}
                {{ 0.2323}}
            {% else %}
                {{ 0 }}
            {% endif %}

Il s’agit du tarif horaire, ne comprenant pas la taxe d’abonnement de 9CHF / mois mais comprenant : Electricité + acheminement + taxe Swissgrid+ Taxe valais + TVA.

Il est ensuite possible de configurer les senseur pour l’import / export d’énergie:


1
2
3
4
5
6
7
8
9
10
11
12
13
14
sensor:
  - platform: integration
    name: Grid Import Energy
    source: sensor.grid_import_power
    unit_prefix: k
    unit_time: h
    method: left

  - platform: integration
    name: Grid Export Energy
    source: sensor.grid_export_power
    unit_prefix: k
    unit_time: h
    method: left

ainsi qu’un « utility_meter » pour le tarif:


1
2
3
4
5
6
7
8
utility_meter:
  daily_energy:
    source: sensor.grid_import_energy
    name: Daily Import Meter
    cycle: daily
    tariffs:
      - hp
      - hc

ainsi que l’automatisation pour la bascule du tarif (dans automations.yaml)

En 2024, le tarif heure creuse est valable de 22h à 7h en semaine ainsi que les week-end.


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
- id: '<random>'
  alias: HP/HC Romange Energie
  description: ''
  trigger:
  - platform: time
    at: 06:00:00
    variables:
      tariff: hp
  - platform: time
    at: '22:00:00'
    variables:
      tariff: hc
  condition:
  - condition: time
    weekday:
    - mon
    - tue
    - wed
    - thu
    - fri
  action:
  - action: select.select_option
    target:
      entity_id: select.energy_meter_tarif
    data:
      option: '{{ tariff }}'
  mode: single

Sur un tableau de bord simple, cela donne :

Il faut ensuite configurer ces entités dans le module Energie de Home Assistant :

En particulier, préciser le tarif pour la consommation du réseau et l’énergie retournée au réseau:

Résultat (un jour pluvieux):

Nous avons maintenant un coût journalier (actualisé plusieurs fois par jour) qui peut être consolidé par période (semaine, mois, année).

Source: Enphase Envoy with Energy Dashboard – Share your Projects! – Home Assistant Community (home-assistant.io)

Catégorie : Home Assistant | Tag , , | Laisser un commentaire

Configurer Starship avec WSL pour booster sa productivité

Starship est un prompt « cross-shell », amélioré, ultra-rapide et personnalisable.

En cherchant comment personnaliser l’affichage de mon shell dans différente conditions, je suis tombé sur starship qui présente de nombreux avantages:

  • multi-shell
  • compatible avec WSL
  • personnalisable
  • performant, avec un faible impact sur les ressources

L’installation est on ne peut plus simple et est décrite sur la page de documentation. Ci-après, je décris comment l’installer sous n’importe quelle distribution Linux WSL (Debian dans mon cas):

  1. Lancer le script d’installation :
    1
    curl -sS https://starship.rs/install.sh | sh
  2. Ajouter la ligne suivante à la fin de ~/.bashrc
    1
    eval "$(starship init bash)"
  3. Recharge la config bash:
    1
    source ~/.bashrc

Starship est maintenant installé. Vous l’aurez remarqué, l’affichage est un peu « buggé ». C’est normal, il faut encore ajouter une Font supportant les icones. Pour ça, il y a l’excellent site nerdfonts.com. Dans mon cas j’ai choisi le « Hack Nerd Font ». L’installation est on ne peut plus simple:

  1. Télécharger le font (sous Windows)
  2. Ouvrir les fichiers polices souhaités et clicker sur « Installer

Il reste deux étapes importantes à effectuer pour avoir un prompte hyper pratique:

La première, il faut configurer la police installée dans le Terminal Windows: Paramètre -> Debian -> Apparence

La deuxième étape, il faut customiser starship. Ca s’effectuer en éditant le fichier ~/.config/starship.toml.

Exemple de ma configuration (attention, les icônes ne seront pas reprise correctement car la police n’est pas installée sur ce site, il faut les adapter selon votre besoin. Ce fichier se trouve également sur mon repo Github


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
# ~/.config/starship.toml

add_newline = false
command_timeout = 1000
format = """$os$username$hostname$kubernetes$directory$git_branch$git_status"""

# Drop ugly default prompt characters
[character]
success_symbol = ''
error_symbol = ''

# ---

[os]
format = '[$symbol](bold white)'
disabled = false

[os.symbols]
Windows = ''
Arch = '󰣇'
Ubuntu = ''
Macos = '󰀵'

# ---

# Shows the username
[username]
style_user = 'white bold'
style_root = 'black bold'
format = '[$user]($style)'
disabled = false
show_always = true

# Shows the hostname
[hostname]
ssh_only = false
format = '@[$hostname](bold yellow):'
disabled = false

# Shows current directory
[directory]
truncation_length = 10
truncation_symbol = '…/'
home_symbol = '󰋜 ~'
read_only_style = '197'
read_only = '  '
format = '[$path]($style)[$read_only]($read_only_style)> '
truncate_to_repo = true
# Shows current git branch
[git_branch]
symbol = ' '
format = '\([$symbol$branch]($style)\)'
# truncation_length = 4
truncation_symbol = '…/'
style = 'bold green'

# Shows current git status
[git_status]
format = '[$all_status$ahead_behind]($style) '
style = 'bold green'
conflicted = '🏳'
up_to_date = ''
untracked = ' '
ahead = '⇡${count}'
diverged = '⇕⇡${ahead_count}⇣${behind_count}'
behind = '⇣${count}'
stashed = '$ '
modified = ' '
staged = '[++\($count\)](green)'
renamed = '» '
deleted = '✘ '

# Shows kubernetes context and namespace
[kubernetes]
format = 'via [󱃾 $context\($namespace\)](bold purple) '
disabled = true

# ---

[vagrant]
disabled = true

[docker_context]
disabled = true

[helm]
disabled = true

[python]
disabled = true

[nodejs]
disabled = true

[ruby]
disabled = true

[terraform]
disabled = true

Une fois le fichier starship.toml, la prochaine ligne de shell sera directement à jour avec la configuration.

Quelques exemples du résultat dans le Terminal (j’ai masqué mes info host/machine):

La dernière étape consiste à configurer VSCode pour supporter l’affichage. Comme pour le Terminal, il faut lui préciser la police à utiliser, sans quoi, les icônes ne seront pas affichées:

Dans settings.json, ajouter les configurations suivante, selon vos préférences :


1
2
"terminal.integrated.fontFamily": "Hack Nerd Font Mono",
"terminal.integrated.fontSize": 12

Voilà VSCode configurer avec starship dans le terminal WSL. La méthode s’applique dans d’autres terminaux également ce qui permet de retrouver une uniformité entre différents shell avec un niveau élevé de personnalisation assurance un gain en productivité

Catégorie : Windows | Tag , , | Commentaires fermés sur Configurer Starship avec WSL pour booster sa productivité

ElasticSearch sur NAS Synology + Docker

Ce guide va présenter comment configurer ElasticSearch et Kibana sur un NAS Synology avec Docker. Le but n’est pas d’avoir une machine ultra-performante mais de pouvoir avoir une installation ElasticSearch facilement maintenable pour des tests ou juste découvrir l’outil. Il sera ainsi possible de mettre à jour rapidement la version dl’ElasticSearch sans perdre de données grâce à l’utilisation de Docker.

Récupération des images Docker

Récupérer les images elastic/elastic-search et elastic/kibana, ce sont les images officielles. Si vous possédez un Synology équiper d’un processeur 64bit, vous pouvez utiliser l’image amd64.

Création des conteneurs: elasticsearch

Pour créer un conteneur, aller dans Image, sélectionner l’image, puis « Lancer »:

Ensuite, choisir « Paramètres avancés »

Paramètres généraux: choisir le nom du conteneur

Volume: configurez deux dossier, config et data avec accès en écriture. C’est là que seront stockés les configurations ainsi que les données des indexes

Fichier/Dossier: le répertoire sur votre NAS, à définir selon votre structure de répertoire.

Chemin d’accès:

/usr/share/elasticsearch/config

/usr/share/elasticsearch/data

Configurer les ports locaux pour les ports du conteneur 9200 et 9300 du conteneur elasticsearch.

Dans environnement, ajouter le paramètre discovery.type = single-node

Création des conteneurs: kibana

Similaire à elasticsearch:

Pour les ports locaux, attention de bien le spécifier, sans ça, impossible d’accéder à Kibana (port 5601 par défaut)

Configuration elasticsearch et kibana

Dans elasticsearch.yml, activer la sécurité: xpack.security.enabled: true. Pour plus de détail: https://www.elastic.co/guide/en/elasticsearch/reference/7.11/get-started-enable-security.html

redémarrer le conteneur puis, dans le shell, mettre à jour les mots de passe (attention de ne pas les perdre, en particulier celui de kibana_system):
./bin/elasticsearch-setup-passwords interactive

Dans kibana.yml, configurer le mot de passe kibana_system selon ce qui a été défini dans le conteneur elastic. Adapter le port elasticsearch si nécessaire.

Voici le miens:

server.name: kibana
server.host: « 0 »
elasticsearch.username: « kibana_system »
elasticsearch.password: « ********** »
elasticsearch.hosts: [ « http://elasticsearch:9200 » ]
monitoring.ui.container.elasticsearch.enabled: true

Le paramètre elasticsearch.hosts tel que défini nécessite de lier les deux conteneurs:

Démarrer les deux conteneur (vous pouvez lier kibana à elasticsearch pour qu’ils soient démarrés en même temps)

Accéder à l’URL de votre NAS avec le port spécifié pour Kibana, vous devriez avoir la page de login qui s’ouvre, pour ensuite accéder à Kibana.

Catégorie : Coding, ElasticSearch | Tag , , , | Commentaires fermés sur ElasticSearch sur NAS Synology + Docker

Windows 10: installation de WSL2 et Debian

Le build 19013 de Windows 10 est disponible depuis peu pour les Insider du programme « lent » (ie, qui présente le moins de risques d’instabilité):

Configuration en Insider « Lent »

Concrètement, cela permet d’installer WSL2, disponible depuis le build 18917 : https://docs.microsoft.com/en-us/windows/wsl/wsl2-install

Par la suite, il est possible d’installer différentes distributions Linux: Debian, Ubuntu, Alpine, …

shell debian

A suivre: les premières expériences avec WSL2.

Catégorie : Uncategorized | Tag , , | Commentaires fermés sur Windows 10: installation de WSL2 et Debian

Tensorflow sur Google Colab

En voulant tester quelques bouts de code utilisant Tensorflow, j’ai constaté que mon PC datait un peu: il n’a pas de support CPU supportant les instructions AVX.

Une version « raspberry-pi » existe depuis 2018 mais elle est loin de permettre de travailler efficacement. L’exemple classic sur le dataset MNIST prend en effet un temps assez conséquent à s’exécuter:

import tensorflow as tf
mnist = tf.keras.datasets.mnist

(x_train, y_train),(x_test, y_test) = mnist.load_data()
x_train, x_test = x_train / 255.0, x_test / 255.0

model = tf.keras.models.Sequential([
  tf.keras.layers.Flatten(),
  tf.keras.layers.Dense(512, activation=tf.nn.relu),
  tf.keras.layers.Dropout(0.2),
  tf.keras.layers.Dense(10, activation=tf.nn.softmax)
])
model.compile(optimizer='adam',
              loss='sparse_categorical_crossentropy',
              metrics=['accuracy'])

model.fit(x_train, y_train, epochs=5)
model.evaluate(x_test, y_test)

Le résultat avec le raspberry-pi:

pi@raspberrypi:~/tensorflow $ python3 mninst.py 
Downloading data from ...
11493376/11490434 [===] - 2s 0us/step
Epoch 1/5
60000/60000 [===] - 107s 2ms/step - loss: 0.2007 - acc: 0.9407
Epoch 2/5
60000/60000 [===] - 104s 2ms/step - loss: 0.0797 - acc: 0.9758
Epoch 3/5
60000/60000 [===] - 104s 2ms/step - loss: 0.0515 - acc: 0.9835

...

Soit près de 2ms par step.

Depuis une année, Google propose Colab : https://colab.research.google.com qui permet gratuitement un environnement Jupyter avec tensorflow pré-installé. Il y a même des GPU disposition.

CPU:

Epoch 1/5 
60000/60000 [===] - 17s 289us/sample - loss: 0.2223 - acc: 0.9342
Epoch 2/5
60000/60000 [===] - 17s 281us/sample - loss: 0.0969 - acc: 0.9706
Epoch 3/5
60000/60000 [===] - 17s 282us/sample - loss: 0.0696 - acc: 0.9783
Epoch 4/5
60000/60000 [===] - 17s 286us/sample - loss: 0.0532 - acc: 0.9836
Epoch 5/5
60000/60000 [===] - 18s 301us/sample - loss: 0.0442 - acc: 0.9856
10000/10000 [===] - 1s 64us/sample - loss: 0.0715 - acc: 0.9805
[0.07151023466372862, 0.9805]

GPU:

Epoch 1/5 
60000/60000 [===] - 8s 136us/sample - loss: 0.2170 - acc: 0.9358
Epoch 2/5
60000/60000 [===] - 8s 134us/sample - loss: 0.0954 - acc: 0.9718
Epoch 3/5
60000/60000 [===] - 8s 133us/sample - loss: 0.0690 - acc: 0.9781
Epoch 4/5
60000/60000 [===] - 8s 133us/sample - loss: 0.0530 - acc: 0.9830
Epoch 5/5
60000/60000 [===] - 8s 134us/sample - loss: 0.0442 - acc: 0.9853
10000/10000 [===] - 1s 70us/sample - loss: 0.0609 - acc: 0.9807
[0.06085205714175245, 0.9807]

La version CPU sur Colab est plus de 5x plus rapide que sur un raspberry-pi et la version GPU 10x plus rapide (pour l’exemple ci-dessus).

Il peut donc être intéressant de créer ses modèles sur Colab, à condition d’être conscient que Google y a probablement accès…

Catégorie : Uncategorized | Commentaires fermés sur Tensorflow sur Google Colab

Développement Python sous Gentoo sans perturber l’environnement du système

Sous Gentoo, l’environnement Python est particulièrement sensible car il est utilisé par le gestionnaire de packages: portage.
L’outil pip, également utilisable pour installer des paquets Python risque d’interférer avec l’environnement du système.

Il est parfois nécessaire d’avoir des paquets python qui ne sont pas proposé directement par la distribution Gentoo. Dans cette situation, il est préférable d’utiliser virtualenv.

Cet outil permet d’installer un environnement python complètement séparé de celui du système.

Installation:

emerge virtualenv

mkdir ~/virtualenv/dev
cd ~/virtualenv/dev
virtualenv .

activer l’environnement:

source ./bin/activate

et installer les paquets requis

pip install ....

Catégorie : Uncategorized | Tag , | Commentaires fermés sur Développement Python sous Gentoo sans perturber l’environnement du système

Installation environnement crossdev ARM sur Gentoo (x86 32/64)

Il peut être pratique d’avoir un environnement de développement ARM utilisable directement depuis un environnement x86 lorsqu’on ne possède pas d’environnement dédié (périphérique cible, raspberry PI par exemple) ou qu’on ne veut pas émuler tout un système d’exploitation dans Qemu pour lancer un simple binaire.

Les étapes suivantes décrivent comment installer l’environnement de compilation (GCC) ainsi que les outils permettant d’exécuter directement un binaire ARM.

Lire la suite

Catégorie : ARM, Coding, Gentoo | Tag , , , , , , | Commentaires fermés sur Installation environnement crossdev ARM sur Gentoo (x86 32/64)

Bridge Mode avec modem Thomson de UpcCablecom

Il peut arriver que l’on veuille avoir un accès direct au net sans que le modem fasse office de routeur.

Pour se faire, il suffit d’y accéder en utilisant l’URL locale 192.168.100.1 (login/mot de passe par défaut: <vide>/admin).

Ensuite, dans Gateway -> SwitchMode, choisir ‘Disable mode’ au lieu de Legacy RG IPv4 mode.

source: https://support-en.upc-cablecom.ch/app/answers/detail/a_id/6323/~/bridge-mode-with-the-thomson-wlan-modem

Catégorie : Uncategorized | Tag | Commentaires fermés sur Bridge Mode avec modem Thomson de UpcCablecom