(Please trim inclusions from previous messages) _______________________________________________ Gateway 44.130.120.65 (Implementation Test YO2LOJ) is advertising for network 44.130.120.0/24, which covers itself. That's not good, right?

I can't route to this network because it causes a routing loop when tunneling.

-J _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

That's a test setup to see if we could actually do it :-) The idea is to have a BGP announced subnet with a IPIP endpoint inside that subnet, so that tunnel users could connect. This issue was raised by the fact that there are situations when a IPv4 address is not available except the 44net space (e.g. IPv6 only nets).

The basic idea is to create a route for the tunnel endpoint via the default gateway (44.130.120.65 via default in this case), and use that tunnel for the rest of the subnet.

I already updated the Mikrotik script to support this. Ampr-ripd is next (the current version will silently ignore this subnet).

Apart of the existence of that subnet, there are no services available, so pleas just ignore it :-)

Marius, YO2LOJ

oups j'ai oublié un truc :)

mieux comme cela

#include <DallasTemperature.h> #include <OneWire.h> #include <LiquidCrystal.h> #include <Wire.h> #include <Adafruit_BMP085.h>

// Data wire is plugged into port 2 on the Arduino #define ONE_WIRE_BUS 2

// Setup a oneWire instance to communicate with any OneWire devices (not just Maxim/Dallas temperature ICs) OneWire oneWire(ONE_WIRE_BUS);

// Pass our oneWire reference to Dallas Temperature. DallasTemperature sensors(&oneWire);

// initialize the library with the numbers of the interface pins LiquidCrystal lcd(13, 12, 7, 6, 5, 4);

Adafruit_BMP085 bmp;

float Temp; int Alti; float Pression;

void Lecture_Capteur() { // Lecture Température Temp = bmp.readTemperature(); delay(200); Alti = bmp.readAltitude(101500); delay(200); Pression = (bmp.readPressure()*0.01) }

void majlcd() { lcd.clear(); lcd.setCursor(0,0); lcd.print("Temp: "); lcd.print(Temp); lcd.setCursor(0,1); lcd.print("Altitude: "); lcd.print(Alti); lcd.setCursor(0,2); lcd.print("Pression: "); lcd.print(Pression); lcd.print(" hPa");

}

void setup() { Serial.begin(9600); Serial.println("Bonjour Laurent F5IDF !");

// gestion du lcd lcd.begin(20,4); lcd.setCursor(0, 1); lcd.print("Bonjour Laurent F5IDF !"); lcd.setCursor(0, 2); lcd.print("!!! Initialisation !!!");

if (!bmp.begin()) { Serial.println("Dallas Temperature IC Control Library Demo"); while (1) {} // Si PB a suprimmer !! } else { Serial.println("Could not find a valid BMP085 sensor, check wiring!"); } sensors.begin(); delay(2000); lcd.clear(); }

void loop() {

Lecture_Capteur();

Serial.print("Temperature = "); // Serial.print(bmp.readTemperature()); Serial.print(Temp); Serial.println(" *C");

Serial.print("Pressure = "); // Serial.print(bmp.readPressure()*0.01); Serial.print(Pression); Serial.println(" hPa");

// Calculate altitude assuming 'standard' barometric // pressure of 1013.25 millibar = 101325 Pascal Serial.print("Altitude = "); // Serial.print(bmp.readAltitude()); Serial.print(Alti); Serial.println(" meters");

Serial.print("Pressure at sealevel (calculated) = "); Serial.print(bmp.readSealevelPressure()*0.01+34.74); Serial.println(" Pa");

// you can get a more precise measurement of altitude // if you know the current sea level pressure which will // vary with weather and such. If it is 1015 millibars // that is equal to 101500 Pascals. Serial.print("Real altitude = "); Serial.print(bmp.readAltitude(101500)-50); Serial.println(" meters"); /* lcd.print("BARO:"); lcd.print(bmp.readSealevelPressure()*0.01+34.74); */

majlcd()

// call sensors.requestTemperatures() to issue a global temperature // request to all devices on the bus Serial.print("Requesting temperatures..."); sensors.requestTemperatures(); // Send the command to get temperatures Serial.println("Temperature ext:"); Serial.println(sensors.getTempCByIndex(0));

delay(10000);

}

Perhaps, or maybe better, just warning that it's probably a mistake. However, it's moot; that route is no longer in the encap file. - Brian

On Mon, Feb 6, 2017 at 1:32 AM, Andrew Ragone (RIT Alumni) ajr9166@rit.edu wrote:

Shouldn't we be dropping RFC1918 addresses from even being able to show up?