Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.sci.electronics > #189640 > unrolled thread

UDP Probleme

Back to article view | Back to de.sci.electronics

Contents

  UDP Probleme Stefan <df9bi@arcor.de> - 2015-07-18 09:48 +0200
    Re: UDP Probleme Reinhardt Behm <rbehm@hushmail.com> - 2015-07-18 16:03 +0800
      Re: UDP Probleme Marcel Mueller <news.5.maazl@spamgourmet.org> - 2015-07-18 10:44 +0200
        Re: UDP Probleme Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-07-18 10:51 +0200
        Re: UDP Probleme Stefan <df9bi@arcor.de> - 2015-07-18 11:12 +0200
          Re: UDP Probleme Michael Schwingen <news-1326478115@discworld.dascon.de> - 2015-07-19 14:18 +0000
            Re: UDP Probleme Stefan Engler <Lehrerfreund@web.de> - 2015-07-26 11:35 -0700
    Re: UDP Probleme Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-07-18 10:45 +0200
      Re: UDP Probleme Stefan <df9bi@arcor.de> - 2015-07-18 11:15 +0200
        Re: UDP Probleme Christian Zietz <newsgroup.1001@chz.xyz> - 2015-07-18 11:57 +0200
          Re: UDP Probleme Christian Zietz <newsgroup.1001@chz.xyz> - 2015-07-18 18:32 +0200
      Re: UDP Probleme Michael Schwingen <news-1326478115@discworld.dascon.de> - 2015-07-19 14:20 +0000
        Re: Ethernet controller (was: UDP Probleme) Michael Schwingen <news-1326478115@discworld.dascon.de> - 2015-07-19 22:17 +0000
          Re: Ethernet controller Michael Baeuerle <michael.baeuerle@stz-e.de> - 2015-07-20 11:57 +0000
    Re: UDP Probleme Markus Marquardt <usenet1312@o2mail.de> - 2015-07-19 23:02 +0200

#189640 — UDP Probleme

Hallo,

hat zwar mehr mit Software als mit Elektronik zu tun, aber ich versuchs 
trotzdem mal hier.

Wir haben ein Microcontroller-System mit STM32 und ENC28J60. Dieses 
System kommuniziert mit einem externen Webserver (V-Server). Auf dem 
Server läuft ein Python-Script, das auf Kommandos vom Microcontroller 
antwortet.

Der Microcontroller sendet jede Minute ein kurzes UDP-Paket raus, ich 
meine, das wäre Port 10100. Der Server empfängt das Paket, wertet es aus 
und antwortet, z.B. mit einem <ack>.

Das funktioniert soweit ganz gut, wenn wir das hier von mir im Betrieb 
aus machen. Als ich das beim Kunden vorführen wollte, bekam ich aber aus 
dessen Netz keine Verbindung hin. Deren Netzwerkadmin war zu dem 
Zeitpunkt nicht greifbar...

Ich hab mir dann gedacht, für solche Vorführungen baue ich mir eine 
mobile Lösung, also einen Ethernet zu Wlan Adapter bestellt (TP-Link 
TL-WA890EA). Das Ding per Tethering mit meinem Android Smartphone 
(Vodafone) verbunden und den ENC per Patchkabel an den WA890.

Jetzt kann der Server die Datenpakete vom Microcontroller/ENC28J60 
empfangen, aber das Datenpaket vom Server zum Microcontroller geht nicht 
durch.

Ich programmier das jetzt nicht selber und will dem Mitarbeiter der das 
bearbeitet mit ein paar Tips auf die Sprünge helfen.

Deshalb hier die Frage, ob jemand eine Idee hat, woran das liegen kann, 
also jetzt speziell das Problem mit der Mobilfunkverbindung.

Vieleicht ist ja einfach die Wahl des Ports ungünstig...


Gruß

Stefan

[toc] | [next] | [standalone]

#189641

Stefan wrote:

> Hallo,
> 
> hat zwar mehr mit Software als mit Elektronik zu tun, aber ich versuchs
> trotzdem mal hier.
> 
> Wir haben ein Microcontroller-System mit STM32 und ENC28J60. Dieses
> System kommuniziert mit einem externen Webserver (V-Server). Auf dem
> Server läuft ein Python-Script, das auf Kommandos vom Microcontroller
> antwortet.
> 
> Der Microcontroller sendet jede Minute ein kurzes UDP-Paket raus, ich
> meine, das wäre Port 10100. Der Server empfängt das Paket, wertet es aus
> und antwortet, z.B. mit einem <ack>.
> 
> Das funktioniert soweit ganz gut, wenn wir das hier von mir im Betrieb
> aus machen. Als ich das beim Kunden vorführen wollte, bekam ich aber aus
> dessen Netz keine Verbindung hin. Deren Netzwerkadmin war zu dem
> Zeitpunkt nicht greifbar...
> 
> Ich hab mir dann gedacht, für solche Vorführungen baue ich mir eine
> mobile Lösung, also einen Ethernet zu Wlan Adapter bestellt (TP-Link
> TL-WA890EA). Das Ding per Tethering mit meinem Android Smartphone
> (Vodafone) verbunden und den ENC per Patchkabel an den WA890.
> 
> Jetzt kann der Server die Datenpakete vom Microcontroller/ENC28J60
> empfangen, aber das Datenpaket vom Server zum Microcontroller geht nicht
> durch.
> 
> Ich programmier das jetzt nicht selber und will dem Mitarbeiter der das
> bearbeitet mit ein paar Tips auf die Sprünge helfen.
> 
> Deshalb hier die Frage, ob jemand eine Idee hat, woran das liegen kann,
> also jetzt speziell das Problem mit der Mobilfunkverbindung.
> 
> Vieleicht ist ja einfach die Wahl des Ports ungünstig...

Bei UDP wird für jedes Paket eine getrennte Verbindung aufgebaut. D.h., Dein 
Controller schickt was ab. Das ist eine Verbindung.
Der Server will für sein ACK auch eine Verbindung aufbauen. Das geht aber 
nicht, weil Dein Controller wahrscheinlich keine öffentliche IP hat.

In Eurem Netz zu Hause geht das, weil sich beide im gleichen internen Netz 
(wahrscheinlich irgendwas 192.168.x.x) befinden.

Wenn Du das mit TCP machst, könte der Conrtoller di Verbindung aufbauen und 
der Server auf der Bestehenden antworten.

Das obige ist sprachlich nicht ganz korrekt, denn UDP ist connectionless. 
Aber das Prinzip ist wie beschrieben.

-- 
Reinhardt

[toc] | [prev] | [next] | [standalone]

#189642

On 18.07.15 10.03, Reinhardt Behm wrote:
> In Eurem Netz zu Hause geht das, weil sich beide im gleichen internen Netz
> (wahrscheinlich irgendwas 192.168.x.x) befinden.

UDP geht auch, aber Du musst erst ein Loch in eventuell vorhandene 
NAT-Router/Firewalls bohren. Dafür gibt es auch Protokolle, aber es ist 
natürlich einiger Aufwand. Jeder Streaming-Dienst dürfte dasselbe 
Problem gelöst haben. Solange nur ein NAT Router genutzt wird und die 
Verbindung von dahinter initial aufgebaut wird, funktioniert es auch 
vollautomatisch, wie eben bei gängigen Internetanschlüssen.

Hinzu kommt aber, dass alles außer Standardprotokollen von vielen 
Firmen-Firewalls blockiert wird. Wenn das Unternehmensstrategie ist, 
enden deine Bemühungen mit einem eigenen Protokoll genau hier.

Es bleibt dann ausschließlich der Weg über Port 80 (http), der zudem 
auch HTTP-Konform ablaufen sollte, weil etliche Firmen explizite oder 
transparente Zwangsproxies haben, die alles andere blocken oder nicht 
verstehen.

Du Wirst also Web-Services nutzen müssen. SOAP muss nicht unbedingt 
sein. HTTP-Services gehen i.A. auch.


Marcel

[toc] | [prev] | [next] | [standalone]

#189644

On 18.07.2015 10:44, Marcel Mueller wrote:

> Es bleibt dann ausschließlich der Weg über Port 80 (http), der zudem
> auch HTTP-Konform ablaufen sollte, weil etliche Firmen explizite oder
> transparente Zwangsproxies haben, die alles andere blocken oder nicht
> verstehen.

Naja, da kommt man dann vom Hundersten ins Tausendste. Und kann sich
überlegen, welche Arten von Proxies man unterstützen will (HTTP oder
SOCKS oder beides). Transparente Proxies sind in Firmennetzen eher
selten gesehen.

Und allerspätestens wenn man dann will, dass die Applikation "wie der
Browser" seine Proxy automatisch findet, wird's richtig hässlich. Dann
darf man sich eine JavaScript-Engine hinpfuschen, weil die Designer die
brilliante Idee hatten, eine Touring-vollständige Sprache zu verwenden,
um auf einem gegebenen Hostname die passende Proxy zu ermitteln.

Das ist also alles nicht zielführend. Das Produkt sollte genau das
können, was letztlich in der Anwendung gefordert ist und nicht mehr.

Viele Grüße,
Johannes

-- 
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
 - Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org>

[toc] | [prev] | [next] | [standalone]

#189645

Am 18.07.2015 um 10:44 schrieb Marcel Mueller:
> On 18.07.15 10.03, Reinhardt Behm wrote:
>> In Eurem Netz zu Hause geht das, weil sich beide im gleichen internen
>> Netz
>> (wahrscheinlich irgendwas 192.168.x.x) befinden.

Nein, wir haben dem MC im internen Netz mit 192.168.x.x und der Server 
befindet sich beim Provider (Strato). Von unserem Netz aus gehts, vom 
Kundennetz aus nicht.

> UDP geht auch, aber Du musst erst ein Loch in eventuell vorhandene
> NAT-Router/Firewalls bohren.

genau so war das gedacht

> Dafür gibt es auch Protokolle, aber es ist
> natürlich einiger Aufwand.

ok, ich dachte, das Loch ist kurzfristig offen, wenn ein UDP Paket rausgeht

> Jeder Streaming-Dienst dürfte dasselbe
> Problem gelöst haben. Solange nur ein NAT Router genutzt wird und die
> Verbindung von dahinter initial aufgebaut wird, funktioniert es auch
> vollautomatisch, wie eben bei gängigen Internetanschlüssen.
>
> Hinzu kommt aber, dass alles außer Standardprotokollen von vielen
> Firmen-Firewalls blockiert wird. Wenn das Unternehmensstrategie ist,
> enden deine Bemühungen mit einem eigenen Protokoll genau hier.
>
> Es bleibt dann ausschließlich der Weg über Port 80 (http), der zudem
> auch HTTP-Konform ablaufen sollte, weil etliche Firmen explizite oder
> transparente Zwangsproxies haben, die alles andere blocken oder nicht
> verstehen.

verstanden, aber noch nicht ganz akzeptiert... ;-)

Gruß

Stefan

[toc] | [prev] | [next] | [standalone]

#189682

On 2015-07-18, Stefan <df9bi@arcor.de> wrote:
> Am 18.07.2015 um 10:44 schrieb Marcel Mueller:
>> On 18.07.15 10.03, Reinhardt Behm wrote:
>>> In Eurem Netz zu Hause geht das, weil sich beide im gleichen internen
>>> Netz
>>> (wahrscheinlich irgendwas 192.168.x.x) befinden.
>
> Nein, wir haben dem MC im internen Netz mit 192.168.x.x und der Server 
> befindet sich beim Provider (Strato). Von unserem Netz aus gehts, vom 
> Kundennetz aus nicht.

Das heisst, die Firewall des Kunden und deren NAT-Router müssen mitspielen -
ohne Absprache mit deren Netzwerk-Admin ist das unwahrscheinlich.  Bei
vielen Firmen hättest Du Ärger bekommen, den MC überhaupt ohne Rücksprache
mit der IT-Abteilung in deren Netz zu hängen ...

Relativ sicher geht das nur mit HTTP(s) über die Standardports - UDP dürfte
häufig gesperrt sein, TCP über nicht-essentielle Ports je nach Admin auch.

Wenn Du richtig Pech hast, bekommt Dein MC nichtmal Verbindung zum LAN, ohne
sich per 802.1x anzumelden.

Die reine UDP-Lösung ist IMHO nur im LAN brauchbar (d.h. wenn Dein Server im
gleichen Netz steht). Alternativ: LTE-Modul einbauen, so dass Dein Gerät
sein funktionierendes Netzwerk selber mitbringt.

cu
Michael

[toc] | [prev] | [next] | [standalone]

#189967

Am Sonntag, 19. Juli 2015 16:18:45 UTC+2 schrieb Michael Schwingen:
> Das heisst, die Firewall des Kunden und deren NAT-Router müssen mitspielen -
> ohne Absprache mit deren Netzwerk-Admin ist das unwahrscheinlich.  Bei
> vielen Firmen hättest Du Ärger bekommen, den MC überhaupt ohne Rücksprache
> mit der IT-Abteilung in deren Netz zu hängen ...

Es kommt auf den Switch an; wenn man Pech hat ist der Port des Switches jetzt
dauerhaft deaktviert und eine Alarm-Nachricht liegt am Controler-Switch.

Eine normale (sicherheitsbewusste) Config eines Switches bzgl. der Access-Ports 
verhindert die Anbindung weiterer Switches und unbekannter Geräte.
 
> Die reine UDP-Lösung ist IMHO nur im LAN brauchbar (d.h. wenn Dein Server im
> gleichen Netz steht). Alternativ: LTE-Modul einbauen, so dass Dein Gerät
> sein funktionierendes Netzwerk selber mitbringt.

Eine http konforme Lösung wäre am einfachsten und flexibelsten.
Leidgeplate Admins sind schon zufrieden wenn überhaupt IP benutzt wird.

Gemäß der Beschreibung erfüllt das ACK keinen Sinn und könnte demanch weggelassen werden. Dann braucht es auch keine zweiseitige UDP-Verbindung.

Das TCP im Mobilfunk besser ist, kann ich nicht bestätigen. 
In D bin ich mit TCP besser dran und in A ist UDP zuverlässiger und TCP dafür
(von HTTP abgesehen) kaum möglich.

[toc] | [prev] | [next] | [standalone]

#189643

On 18.07.2015 09:48, Stefan wrote:

> Deshalb hier die Frage, ob jemand eine Idee hat, woran das liegen kann,
> also jetzt speziell das Problem mit der Mobilfunkverbindung.

Ich würde als erstes ausprobieren, ob dein Mobilfunkprovider überhaupt
UDP routet. Es gibt einige, die UDP nicht zulassen, weil sie nicht
wollen, dass man VoiP über die Datenverbindung fährt. Also einfach mal
einen UDP-Server per netcat oder so laufen lassen und Pingpong spielen,
das ganze mit Wireshark aufzeichnen. Dann hast du in 5 Minuten Gewissheit.

Noch eine zusätzliche Info: Der ENC28J60 macht nur 10 MBit. Ich bin auch
schon mal reingefallen, als ich den Fall erlebt hatte, dass ein moderner
GBit-Switch keine 10 MBit mehr unterstützt hat. Hätte eigentlich
erwartet, dass die *immer* rückwärtskompatibel sind, sind aber offenbar
auch nicht alle. Fürs Produkt ist es dann ein ENC424J600 geworden, der
ist auch nicht so megabeschissen designed wie sein Bruder.

Viele Grüße,
Johannes

-- 
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
 - Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org>

[toc] | [prev] | [next] | [standalone]

#189646

Am 18.07.2015 um 10:45 schrieb Johannes Bauer:
> On 18.07.2015 09:48, Stefan wrote:
>
>> Deshalb hier die Frage, ob jemand eine Idee hat, woran das liegen kann,
>> also jetzt speziell das Problem mit der Mobilfunkverbindung.
>
> Ich würde als erstes ausprobieren, ob dein Mobilfunkprovider überhaupt
> UDP routet. Es gibt einige, die UDP nicht zulassen, weil sie nicht
> wollen, dass man VoiP über die Datenverbindung fährt. Also einfach mal
> einen UDP-Server per netcat oder so laufen lassen und Pingpong spielen,
> das ganze mit Wireshark aufzeichnen. Dann hast du in 5 Minuten Gewissheit.

Wie schon geschrieben: in die eine Richtung funktioniert es. Am Server 
sehen wir die Datenpakete, aber der ENC bekommt keine Antwort

> Noch eine zusätzliche Info: Der ENC28J60 macht nur 10 MBit. Ich bin auch
> schon mal reingefallen, als ich den Fall erlebt hatte, dass ein moderner
> GBit-Switch keine 10 MBit mehr unterstützt hat. Hätte eigentlich
> erwartet, dass die *immer* rückwärtskompatibel sind, sind aber offenbar
> auch nicht alle. Fürs Produkt ist es dann ein ENC424J600 geworden, der
> ist auch nicht so megabeschissen designed wie sein Bruder.

ok, werd ich mal prüfen


>
> Viele Grüße,
> Johannes
>

[toc] | [prev] | [next] | [standalone]

#189649

Stefan schrieb:

> Wie schon geschrieben: in die eine Richtung funktioniert es. Am Server 
> sehen wir die Datenpakete, aber der ENC bekommt keine Antwort

Der Server sendet die Antwort auch an die Portnummer von der er die
Anfrage bekommen hat und nicht an eine hartkodierte Portnummer? NATs
müssen die Quellportnummer ggf. ändern, um Kollisionen zu vermeiden.

Also:

uC sendet:
von: Interne-IP:Quellport
an:  Server-IP:Zielport

NAT-Endpunkt macht daraus:
von: Öffentliche-IP:Zufälliger-Port
an:  Server-IP:Zielport

Dann muss der Server natürlich an "Öffentliche-IP:Zufälliger-Port"
antworten und nicht an "Öffentliche-IP:Quellport". UDP-Pakete an andere
Ports als "Zufälliger-Port" werden nicht durch die NAT an den uC
durchgereicht.

Siehe <http://tools.ietf.org/html/rfc4787#section-4.1>

Christian
-- 
Christian Zietz  -  CHZ-Soft  -  czietz (at) gmx.net
WWW: http://www.chzsoft.de/
PGP/GnuPG-Key-ID: 0x52CB97F66DA025CA / 0x6DA025CA

[toc] | [prev] | [next] | [standalone]

#189660

Stefan schrieb:

> Das Python Script auf der Server Seite horcht nur auf Port 10100 und 
> antwortet auf 10100 wenn er ein gültiges Telegramm erhalten hat.

Das ist schlecht, wenn der NAT-Endpunkt die Quell-Portnummer umschreibt.
Guckt doch auf dem Server mal nach, von welcher Portnummer die Pakete
dort eintreffen.

Christian
-- 
Christian Zietz  -  CHZ-Soft  -  czietz (at) gmx.net
WWW: http://www.chzsoft.de/
PGP/GnuPG-Key-ID: 0x52CB97F66DA025CA / 0x6DA025CA

[toc] | [prev] | [next] | [standalone]

#189683

On 2015-07-18, Johannes Bauer <dfnsonfsduifb@gmx.de> wrote:
> Noch eine zusätzliche Info: Der ENC28J60 macht nur 10 MBit. Ich bin auch
> schon mal reingefallen, als ich den Fall erlebt hatte, dass ein moderner
> GBit-Switch keine 10 MBit mehr unterstützt hat. Hätte eigentlich
> erwartet, dass die *immer* rückwärtskompatibel sind, sind aber offenbar
> auch nicht alle. Fürs Produkt ist es dann ein ENC424J600 geworden, der
> ist auch nicht so megabeschissen designed wie sein Bruder.

Ich weiß ja nicht - wenn man schon einen STM32 hat, dann kann man auch einen
mit integriertem Ethernet nehmen und einen klassichen MII-PHY anschließen -
dann hat man den ganzen Protokollstapel unter eigener Kontrolle.

cu
Michael

[toc] | [prev] | [next] | [standalone]

#189694 — Re: Ethernet controller (was: UDP Probleme)

On 2015-07-19, Michael Baeuerle <michael.baeuerle@gmx.net> wrote:
>
>> Ich weiß ja nicht - wenn man schon einen STM32 hat, dann kann man auch einen
>> mit integriertem Ethernet nehmen und einen klassichen MII-PHY anschließen -
>> dann hat man den ganzen Protokollstapel unter eigener Kontrolle.
>
> Das hat man mit externem MAC auch. Ob die Ethernet-Adresse mitgeliefert
> wird oder man selbst eine organisieren muss ist auch noch interessant.

Hm, stimmt, ich habe den anscheinend mit diesen Teilen mit integriertem
IP-Stack (Wiznet?) verwechselt. Aber auch dann würde ich den integrierten
MAC (mit 100MBit/s und DMA) vorziehen.

Ich bin eigentlich der Meinung, daß ein 1000BaseT-Switch zwingend 10BaseT
können muss, um standardkonform zu sein - kann es sein, daß da eines der
vielen Errata des Chips greift?

cu
Michael

[toc] | [prev] | [next] | [standalone]

#189717 — Re: Ethernet controller

Matthias Weingart wrote:
> Lutz Schulze <lschulze@netzwerkseite.de>:
> > Am 19 Jul 2015 22:17:49 GMT schrieb Michael Schwingen:
> > > 
> > > Ich bin eigentlich der Meinung, daß ein 1000BaseT-Switch zwingend
> > > 10BaseT können muss, um standardkonform zu sein - kann es sein, daß da
> > > eines der vielen Errata des Chips greift?
> > 
> > Ich bekomme auch mitunter Rückmeldungen von Kunden, dass deren
> > Gigabit-Switche 10 MBit nicht mher unterstützen - allerdings ist das
> > sehr selten.
> 
> Oder vielleicht ist es auch nur die fehlende Autoneg. und mit einem (schon 
> fast vergessenen) Cross-Over-Kabel würde es laufen?

Bei dem Problem mit dem CP2200 am 1000BaseT-Switch kann ich das aus-
schließen. Das Kabel war passend (und der CP2200 beherrscht neben Auto-
Negotation für Speed und Duplex-Mode prinzipiell auch Auto-Crossover).

Ob der Switch das nun gar nicht unterstützte, oder nur besonders
pingelig war und ihm vielleicht das Signal des CP2200 nicht gefallen
hat, kann ich nicht mit Sicherheit sagen.
Der CP2200 hat ein Errata im Transmitter, das soll aber mit einem
normkonformen Empfänger keine Problem verursachen.
Mit anderen 10/100/1000 Switches hat es dann auch funktioniert.

[toc] | [prev] | [next] | [standalone]

#189691

Am 18.07.2015 09:48, schrieb Stefan:

> Das funktioniert soweit ganz gut, wenn wir das hier von mir im Betrieb
> aus machen. Als ich das beim Kunden vorführen wollte, bekam ich aber aus
> dessen Netz keine Verbindung hin. Deren Netzwerkadmin war zu dem
> Zeitpunkt nicht greifbar...

Wie schon erwähnt ist UDP ein verbindungsloses(!) Protokoll. Viele 
Firewalls erlauben aber dennoch ankommende "Antwortpakete" wenn vorher 
aus dem internen Netz ein UDP Paket nach extern geschickt wurde.

Die erste Frage wäre, ob ausgehende Pakete zu diesem Port überhaupt 
erlaubt sind, normalerweise wird auf Firewalls die "was nicht 
ausdrücklich erlaubt ist, ist verboten" Strategie implementiert -> Paket 
wird sowieso gefiltert.

Die NAT-Problematik wurde ja schon erwähnt. Ein NAT-Router oder Firewall 
werden auf jeden Fall den Absenderport modifizieren, so dass es nicht 
mehr Port 10100 ist. D.h. der Daemon auf dem externen Server muss das 
Antwortpaket an den Zielport schicken, den er im empfangenen Datagramm 
als Absenderport bekommen hat.

> Deshalb hier die Frage, ob jemand eine Idee hat, woran das liegen kann,
> also jetzt speziell das Problem mit der Mobilfunkverbindung.

Ich bin mir auch nicht sicher ob man auf dem Mobiltelefon eine 
ÖFFENTLICHE IP-Adresse erhält, oder ob die Provider dort auch private 
RFC1918 Adressen verwenden, ich meine ich hätte mal sowas gesehen...

Da trifft dann das oben gesagte mit dem NAT genauso zu, da der Provider 
ja irgendwo dann einen Übergang in das Internet hat, wo er NAT machen muss.

Ciao...
Markus

[toc] | [prev] | [standalone]

Back to top | Article view | de.sci.electronics

csiph-web