Re: [reti-accesso] Porta client DHCP - caccia al tesoro

[Lorenzo Bracciale < >]

E' corretto! anche la risposta di The_Dreamer era corretta ma 
incomprensibile perche' aveva trovato una versione tradotta delle rfc. 
E' molto meglio leggere dall'inglese e dalla fonte originale:
http://www.rfc-editor.org/rfc/rfc951.txt
--------
The reason TWO reserved ports
  are used, is to avoid 'waking up' and scheduling the BOOTP server
  daemons, when a bootreply must be broadcast to a client.  Since the
  server and other hosts won't be listening on the 'BOOTP client' port,
  any such incoming broadcasts will be filtered out at the kernel
  level.  We could not simply allow the client to pick a 'random' port
  number for the UDP source port field; since the server reply may be
  broadcast, a randomly chosen port number could confuse other hosts
  that happened to be listening on that port.
----------
In altre parole quando ci colleghiamo con firefox a google, l'unica 
porta che ci serve sia standardizzata è la porta server http ovvero la 
80. La risposta ci tornerà in un pacchetto IP destinato solo a noi, e 
avente come porta destinazione la porta effimera  con cui abbiamo 
originato la richiesta.
Con DHCP è diverso. Noi non abbiamo ancora un IP quindi la risposta 
potrebbe essere ricevuta anche da altri host.
Se scegliessimo una porta effimera, il messaggio di risposta potrebbe 
arrivare a tutti gli host della nostra sottorete (broadcast) su quella 
porta effimera che abbiamo scelto solo noi.
Se un'altro host ha un'altra applicazione che ascolta su quella stessa 
porta , la nostra risposta dhcp potrebbe arrivargli e "confondere" la 
sua applicazione.
Per evitare di generare problemi alle applicazioni, si è preferito 
fissare anche la porta del client. In questo modo quando una risposta 
arriva in broadcast ad un host che non ha un dhcp client attivo , il 
kernel di questo host la butterà perchè non troverà nessuna applicazione 
a cui interessano i pacchetti che arrivano su quella porta.


A domani, Lorenzo

Bruno Ricci ha scritto:
> Fonti:
> http://www.rfc-editor.org/rfc/rfc951.txt
> http://www.tcpipguide.com/free/t_BOOTPClientServerMessagingandAddressing-2.htm 
>
>
> Sostanzialmente, se non usassi una porta "fissa" anche lato client, il 
> server non potrebbe determinare con certezza la porta a cui mandare il 
> messaggio di risposta ad una richiesta BOOTP/DHCP, poichè
> a) la trasmissione di tale risposta *può* essere effettuata in broadcast
> b) la porta selezionata come destinazione della risposta potrebbe 
> essere già in uso da altri "processi" come porta random
>
> ...ho toppato, vè? :)
>
> Bruno
>
>
>
> Lorenzo Bracciale ha scritto:
> > Ricordo il quesito per la "caccia al tesoro":
> > Trovare il perchè nel protocollo dhcp viene definita una porta 
> > specifica *anche* per il client, a differenza ad esempio di http (e 
> > della maggior parte degli altri protocolli) dove l'unica porta 
> > definita è quella server (ad es. la 80 per http).
> >
> > Mandate la risposta (e la fonte) il mailing list.
> > Ciao,
> >
> > Lorenzo